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Executive  Summary 

The  objective  of  this  research  was  Ho  design  and  implement  :* 
model  building  methodology  for  simulating  U/S,  Army  computer  hardware/ 
software  systems.  Computer  systems  are  characterized  in  terms  of 
file  parameters,  hardware  specification,  and  software  use  of  files. 
These  descriptions  reside  in  a  model  library  and  are  the  building 
blocks  in  the  model  synthesis  process.  The  Information  Processing 
System  Simulator  (TPSS)  language  was  used  to  encode  these  descriptions 
and  to  represent  the  sequence  of  computer  activities  for  application 
program  processing  (e.g.,  job  scheduling,  buffer  management,  channel 
program) . 

Two  computer  systems  were  compared  using  this  methodology.' 
Simulation  models  were  written  for  an  IBM  360  Model  30  computer  and 

V 

a  Honeywell  Level  6  minicomputer.  A  subset  of  the  U.S*  Army  Standard 
Installation/Division  Personnel  System  (SIDPERS)  provided  a  common 
loading  for  both  systems.  Data  was  collected  on  an  operational  IBM 

■f 

360/30  and  the  IPSS  model  was  validated.  The  statistical  results, 
derived  from  IPSS^ indicate  resource  utilization  (for  both  hardware  and 

software  resources),  elapsed  time,  and  queueing.  Our  results  project 

. . %- 


that  an  eight;  hour  execution  of  SIDPERS  on  the  IBM  360/30  would  execute 

1  y  ~  _ 

*  •  O  "  'X 

in  approximately f two  and  one-half-hours  on  the  Honeywell  machine.  Models 
of  several  hardware  variations  were  prepared  in  order  to  demonstrate 
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PriEGEDl  NS  PASS  BLANK -NOT  FILLED 

1.  INTRODUCTION 

This  report  is  in  response  to  the  Laboratory  Research  Cooperative 
Program  Statement  of  Work  TCN:  79-245,  which  required  the  services  of 
three  research  scientists  on  a  short-term  project  to  develop  simulation 
models  of  computer  systems.  The  objective  of  this  research  was  to 
produce  a  model  building  methodology  using  the  Information  Processing 
System  Simulator  (IPSS)  to  develop  a  ranking  and  evaluation  procedure 
for  computer  hardware/software  systems.  Five  specific  tasks  were 
identified: 

1.  Using  IPSS,  specify,  design,  build,  test,  validate,  verify 
and  document  a  model  of  an  existing  Army  computer  hardware/ 
software  system  (such  as  the  U.S.  Army  Base  Operations 
System  (BASOPS)  implemented  on  IBM  360/40  equipment). 

2.  Using  IPSS,  specify,  design,  build,  test,  validate,  verify 
and  document  a  model  of  an  advanced  Army  computer  hardware/ 
software  system  (such  as  a  minicomputer  data  base  oriented 
sys  tern) . 

3.  Specify  and  collect  data  needed  to  build  the  models  of 
computer  hardware/software  systems  specified  in  1  and  2 
above . 

^,4.  Develop  measures  to  allow  for  the  ranking  and  evaluation  of 
computer  hardware/software  systems.  Factors  should  include, 
but  not  be  limited  to,  growth  rate,  workload,  software, 
variance  in  configurations,  and  new  applications. 


5.  Arrange  for  and  provide  computer  support  services,  to  include 
computer  time,  disk  storage,  and  IPSS  software  support. 
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This  final  report  to  AIRMTCS  reflects  the  background  activity, 
purpose,  procedures,  documentation,  and  summary  of  work  performed  under 
each  of  the  above  tasks. 

Tasks  1,  2,  3  and  5  have  been  completed  in  full;  we  could  not 
complete  task  4  due  to  lack  of  time.  As  the  Army  is  considering 
replacement  of  certain  of  its  computer  systems,  we  did  consider, 
relative  to  task  4,  measures  for  evaluating  computer  systems  when  the 
major  factor  is  variance  in  hardware  configurations. 

1.1  SUMMARY  OF  RESEARCH  ACTIVITIES 

The  primary  objective  of  this  project  was  accomplished  by 
designing,  building,  testing,  verifying,  and  validating  two  basic 
models  of  Army  computer  systems.  The  first  model  was  of  an  existing 
Army  computer  system,  namely,  an  IBM  360  Model  30  with  a  selected 
subset  of  the  Standard  Installation  Division  Personnel  System  (SIDPERS) 
basic  cylce  for  loading.  This  model  provided  a  frame  of  reference 
and  was  validated.  The  second  model  was  of  an  advanced  computer  system 
(one  not  currently  operational)  that  was  considered  to  be  typical  of 
potential  Army  purchases.  This  system  was  a  Honeywell  Series  60  Level 
6  Model  47  minicomputer  with  the  same  SIDPERS  basic  cycle  for  loading. 
Several  variations  on  the  basic  hardware  architecture  were  modeled  and 
analyzed . 

These  models  were  compared  against  the  same  workload,  the  first 
four  jobsteps  of  SIDPERS.  The  results  of  such  comparisons  allow  for 
a  relative  ranking  of  the  various  systems.  Such  a  ranking  is  the  first 
step  towards  determining  what  computer  will  meet  the  needs  of  the  location 
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being  examined.  The  [PSS  approach  is  unique  in  that  almost  all 
currently  available  simulation  techniques  deal  only  with  representative 
bate f  oriented  systems  while  IPSS  has  special  facilities  which  will 
allow  the  modeling  of  advance d  computer  features  such  as  data  bases, 
networks,  and  interactivity. 

Of  primary  concern  is  the  acceptance  of  the  modeling  methodologv 
within  the  Army.  Thus  we  have  concentrated  on  validating  a  model  of 
a  simple  and  typical  hardware/software  system.  The  underlying 
assumption  is  chat  credibility  will  transfer  to  models  of  more 
advanced  systems  given  a  well  validated  basic  model. 

At  the  start  of  the  project,  AIRMICS  personnel  provided  us 
assistance  in  selecting  the  computer  systems  that  we  were  to  model. 
After  a  preliminary  investigation  of  the  type  of  processing  SIDPERS 
performs  and  the  hardware  configurations,  we  proceeded  as  follows: 

1.  Developed  the  IPSS  Application  Processing  System  (IAPS) 
methodology  for  representing  application  systems  processing. 

2.  Implemented  the  methodology  in  IPSS. 

3.  Collected  data  on  four  SIDPERS  job  steps  and  the  two  computer 
hardware  configurations. 

4.  Coded  the  hardware  and  software  descriptions  for  the  above 
in  IPSS. 

'> .  Vet'll  it’d  the  IPSS  models. 

(>.  Val  id.  it  eil  the  model  ot  the  I RM  360/30. 

/.  Performed  experiments  using  alternate  hardware  configurations. 

5.  Ana  I  v /.ini  tin  it-. sul  is. 
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1.2  SUMMARY  OF  RESULTS 

This  section  summarizes  the  major  cent r ihut ion  of  our  research 
project.  These  results  are  discussed  in  detail  in  the  sections 
re  I  erencei! . 

First,  we  demonstrated  the  appropriateness  of  us  i  up,  IPSS  for 
model  ini;  typical  U.S.  Army  computer  hardware/software  systems,  and 
showed  that  the  simulation  technique  can  provide  data  useful  for  the 
comparison  of  alternative  computer  systems.  To  ease  the  task  of 
modeling  in  IPSS,  we  provided  a  high  level  modeling  approach  through 
our  IPSS  Application  Processing  System  (IAPS)  methodology  which  is 
able  to  accommodate  any  level  of  detail  desired  by  the  simulation 
user.  (See  Chapter  3) 

In  conjunction  with  IAPS,  we  established  a  basic  library  of 
model  components  which  allows  a  user  to  easily  and  quickly  build  a 
model  of  a  large  number  of  design  alternatives.  This  library  can 
be  modified  and  the  number  of  its  members  increased  so  as  to  enhance 
future  Army  modeling  needs.  The  library  as  it  currently  exists  is 
described  in  Appendix  E. 

We  identified  the  types  of  verification  and  validation  data  needed 
and  their  sources  within  the  U.S.  Army  Computer  Systems  Command.  (See 
Chapter  4)  The  ready  availability  of  needed  data  would  greatly  shorten 
the  time  needed  to  complete  any  future  modeling  efforts. 

We  demonstrated  the  feasibility  of  the  TAPS  methodology,  and  tin- 
usefulness  of  the  data  collected  by  modeling  and  comparing  several 
design  alternatives  for  the  Army  CS^  hardware/software  svstem.  This 
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effort  included  validation  of  a  model  of  an  existing  system,  development 
of  models  of  nine  alternative  hardware  configurations,  and  a  comparison 
of  the  different  systems.  (Sc  •  Section  5.2  for  the  hardware  alternatives. 
Sections  4  and  5  for  the  SIDPERS  model,  and  Section  7  for  the  simulation 
results.)  In  addition,  we  have  given  a  manpower  analysis  of  the  current 
project  and  several  possible  future  projects.  (See  Section  8.) 

We  identified  appropriate  measures  for  the  comparison  and  ranking 
of  production,  batch  oriented  Army  computer  systems.  Those  measures 
which  can  he  estimated  via  simulation,  and  which  are  collected  automatically 
by  ll’SS,  include  job  elapsed  time,  resource  utilization,  and  queuing 
statistics.  (See  Section  7.) 

All  in  all,  we  believe  that  the  complete  IAPS  simulation  methodology 
is  a  feasible  and  potentially  useful  approach  in  the  Army's  evaluation 
and  comparison  of  alternative  computer  systems. 

The  remainder  of  this  report  is  organized  as  follows.  In  Section  2, 
we  discuss  the  background  to  the  project  and  the  motivation  for  our 
modeling  approach.  The  methodology  for  modeling  and  evaluating  computer 
ha rdwa re /so f twa re  systems  is  presented  in  Section  ).  Sections  2,  4,  and 
5  present  the  specific  problems  of  modeling  SlbPKRS  and  the  selected 
computer  hardware  architectures.  Section  b  identifies  the  structure 
of  our  Il’SS  model  while  Section  7  presents  the  results  of  our  modeling 
experiments.  A  summary  of  the  time  required  for  various  modeling 
activities  is  given  in  Section  8.  We  finish  with  a  summary,  recommendations 
and  conclusions  in  Section  9.  A  number  of  Appendices  contain  auxiliary 
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2.  BACKGROUND  AND  APPROACH  TO  COMPUTER  EVACUATION 

.  1  BACKGROUND  TO  THE  PROJECT 

The  United  States  Army  is  about  to  enter  a  period  in  which 
several  largo  purchases  of  computer  hardware/software  systems  are 
to  •  •  i ■  made.  lor  example,  one  purchase  could  involve  the  replacement 
ol  over  40  computer  installations.  Choosing  one  machine  to  work 
at  over  40  places  would  be  complex  enough,  but  in  this  case 
theoretically  there  could  be  over  40  different  machines  chosen. 

A  computer  vendor  can  bid  on  any  number  of  sites  with  any  combination 
of  equipment.  The  workload  profile  at  the  locations  for  the  machines 
is  radically  different.  A  minicomputer  might  work  very  well  at 
one  place  while  another  must  have  a  large  main-frame. 

Currently  the  sites  have  IBM  360/30's,  IBM  360/40's,  and 
IBM  360/50's,  some  with  single  peripherals,  some  with  dual  peripherals, 
some  running  the  DOS  operating  system  (or  the  enhanced  DOS  system 
DOS-E)  and  some  with  OS.  A  major  portion  of  the  software  is  consistent 
from  location  to  location,  but  the  volume  of  transactions  is  dras¬ 
tically  different.  All  current  work  is  batch  oriented. 

The  Army  desires  to  purchase  new  equipment  to  replace  these 
machines.  They  want  to  add  interactive  capabilities  while  retaining 
batch  processing  for  some  applications.  One  requirement  of  the  new 
computers  is  that  they  process  the  current  work  in  one  eight  hour 
shift  five  days  a  week.  (Currently  most  sites  are  running  24  hours 
a  day  five  to  seven  days  a  week). 
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With  recent  technological  advances,  selecting  even  one  computer 
is  almost  beyond  human  capability  if  one  is  to  easily  and  fairly 
compare  all  of  the  machines  that  vendors  would  contend  can  do  a 
given  job.  Current  methods,  such  as  benchmarking,  fall  short  of 
solving  the  problem.  Simulation  appears  to  be  a  very  attractive 
approach  because  of  its  flexibility  and  power  in  representing 
complex  activities.  Thus,  this  project  requires  the  use  of  discrete 
event  digital  simulation  to  assist  in  the  selection  and  evaluation 
of  computer  hardware/software  systems. 

This  project  specifically  r» quired  the  use  of  the  Information 
Processing  System  Simulator  (IPSS)  to  rank  and  evaluate  computer 
hardware/software  systems.  IPSS  is  a  special-purpose  discrete 
event  digital  simulator  system  which  was  specifically  designed  to 
facilitate  the  investigation  of  the  behavior  of  complex  computer- 
based  information  processing  systems  (DEL77,  DEL78a). 

One  significant  feature  of  IPSS  is  its  ability  to  characterize 
a  computer's  I/O  subsystem.  The  IPSS  language  contain.;,  a  rich  set 
of  instructions  for  describing  control  units,  channels,  disk  and 
tape  drives,  and  unit  record  equipment.  The  IPSS  "service"  concept 
permits  a  flexible  characterization  of  the  acquisition,  use  and 
release  of  the  secondary  storage  "facilities". 

These  features  are  important  because  of  the  Army's  predominately 
I/O  oriented  computer  systems.  Thus,  a  detailed  modeling  of  the 
I/O  subsystem  should  be  of  great  potential  value  in  identifying 
boll  leitecks  anil  el  (eels  el  liardwnre/sof tware  changes.  IPSS  provides 
the  capacity  lor  detailed  modeling  of  tliis  computer  subsystem  and 
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also  automatically  collects  elapsed  time,  resource  utilization  and 
queueing  statistics  for  the  user. 

Although  IPSS  is  a  prototype  system,  it  proved  to  be  an  able 
tool  for  characterizing  salient  features  of  SIDPERS  application  as 
well  as  the  hardware  characteristics  of  the  IBM  Model  30  and  the 
Honeywell  Level  t  minicomputer .  An  overview  of  the  IPSS  methodology 
is  provided  in  Appendix  A. 

APPROACH  TO  MODEL  I NC  AND  VALIDATION 

The  completion  of  the  specific  research  tasks  outlined  in 
Section  1  required  the  resolution  of  two  basic  issues,  namely: 

1.  How  to  represent  application  program  software  in  a 
simulation  model,  and 

2.  What  data  was  available  within  the  U.S.  Army  for 
validation  of  simulation  models  of  computer  hardware/ 
software  systems. 

Since  our  resolution  of  these  tusks  was  both  time  consuming  and 
crucial  to  the  results  of  the  project,  an  overview  of  our  approach 
is  given  here. 

The  first  task,  how  to  model  computer  software,  can  be  rephrased 
as:  What  is  the  best  approach  for  modeling  large  software  systems  by 
using  IPSS.  (IPSS  has  considerable  flexibility  and  power  in  represen¬ 
ting  computer  hardware,  so  that  aspect  of  computer  system  modeling 
was  not  a  problem).  Software  systems  such  as  SIDPERS  contain  many 
large  COBOL  programs.  We  recognized  that  a  detailed  statement-by-state- 


ment  or  even  paragraph-by-paragraph  description  of  the  processing  logic 
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would  be  far  Coo  time  consuming  for  this  project.  TPSS  is,  however, 
capable  of  representing  processing  logic  at  this  level  of  detail  and 
this  approach  may  prove  to  be  valuable  for  some  programs,  such  as 
operating  system  routines,  or  for  more  refined  results.  Even  if  this 
approach  were  used,  only  oni  or  two  simple  programs  could  be  character¬ 
ized  in  the  time  allowed,  giving  little  insight  into  the  processing 
characteristics  of  a  large  system.  Clearly,  we  were  challenged  to 
produce  a  faster  modeling  approach  which  would  both  retain  a  useful 
level  of  accuracy  of  the  detailed  approach  and  provide  flexibility 
for  the  modeler. 

S1DPERS,  the  software  system  selected,  has  been  modeled  before 
using  the  software  simulation  package  CASE  (ADL75,  SWE76) .  in 
addition,  an  TPSS  model  of  several  SIDPERS  programs  was  part  of  an 
IPSS  S1DPERS/IDMS  simulation  study  (BR077,  DEL78) ,  and  a  DIMU1  model 
also  simulated  these  programs  (SCH77).  The  methods  for  representing 
software  processing  in  these  models  were  studied  hut  not  adopted 
in  our  methodology.  The  CASE  approach  represents  files  and  file 
processing  in  an  easily-understood  and  consistent  manner,  but  overall 
was  not  judged  to  be  a  suitable  methodology  because  of  its  lack  of 
flexibility  (for  an  evaluation  of  CASE  versus  IPSS  see  ROS78).  The 
previous  IPSS  and  DIMUI  approaches  were  rejected  since  they  modeled 
interactive  SIDPERS  programs  by  representing  every  call  to  a  DBMS 
rent  in.'.  (.The  batch  SIDPERS  programs  that  wo  modeled  requested  I  /  0 
to  munv  types  ol  files  in  tlu*  absence  of  a  DBMS). 

Our  approach  was  to  detail  l /0  processing  on  a  file  by  file 
basis,  and,  in  less  detail,  to  characterize  program  CPU  loading. 

Tliis  is  consistent  with  the  IPSS  methodology  and  also  allows  the 
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modeler  freedom  to  change  the  procedural  structure  of  the  model.  Our 
methodology,  called  I  APS  (II’SS  Application  Processing  System),  is 
reported  in  Section  J. 

The  second  task  we  faced  was  the  selection  of  a  hardware/software 
system  for  which  v. ilid.it  ion  data  existed.  Valiil.it  ion  is  the  process 
ol  determining  the  degree  ol  validity  ol  a  simulation  model.  A  valid 
mode  I  is  one  which  is  capable  of  accurately  measuring,  predicting  and 
representing  a  system.  The  validation  process  proceeds  to  build  an 
acceptable  level  of  confidence  that  an  inference  about  a  simulated 
process  is  a  correct  or  valid  inference  for  the  actual  process.  Valid¬ 
ation  of  a  model  is  performed  by  a  comparison  of  the  recorded  observations 
of  the  real  process  with  simulator  outputs  from  a  verified  model,  thereby 
establishing  the  versimi litude  of  the  model  and  the  real  world  process 
(MlH76a,  MIH76b).  Seldom,  if  ever,  will  validation  result  in  a  "proof" 
lh.il  tin*  model  is  a  correct  or  "true"  represent  at  ion  of  the  real  process 
(VANfdi).  Vcril  ical  ion,  on  the  other  li.uul,  is  the  compa  r  i  son  of  the 
model's  responses  with  t hose  anticipated  if  the  model's  structure  wore 
programmed  as  intended  (MlH7bb).  This  means  testing  the  outputs  of  the 
random  number  generators  as  well  as  checking  that  the  computer  program 
correctly  executes  the  logic  desired  by  the  modeler. 

With  assistance  of  USACSC  personnel  we  decided,  early  in  the  project, 
to  model  a  subset  of  STDPERS  executing  on  the  IBM  Model  30  utilized  at 
the  Division  of  the  Army's  organization  and  to  compare  the  results 
against  a  Honeywell  l.evel  6  Model  47  minicomputer  using  the  same  S1DPF.RS 
workload.  We  also  determined  that  GRASP  step  accounting  data  was  the 
im  is  I  i  mpn  r  (in  I  rc<|u  i  rcmcit  l  lor  a  del  a  i  led  va  I  i  da  I  i  on  o  I  our  si  mu  I  a  (  ion 
models.  Detailed  validation  of  a  SIDPKRS  job  step  requires  the  following: 
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I.  GRASP  step  accounting  data 
.  Tlii‘  operator  console's  log  (tor  the  job  step) 

"3.  SYSLIST  (for  the  job  step) 

4.  Listing  of  specified  data  sets 

5.  VTOC  listing  of  all  disk  packs  which  were  on-line  during 
the  job  step 

6.  Researchers  present  in  the  machine  room  during  execution 
of  the  job  step. 

Since  GRASP  step  accounting  data  was  not  available  on  a  360/30 
but  was  available  on  a  360/30,  we  considered  the  following  alternatives 

A.  Model  the  360/50,  and  validate  the  model 

B.  Model  the  360/30,  which  couldn't  be  validated  in  detail 

C.  Do  both  A  and  B 

The  first  alternative  was  rejected  since  it  would  not  permit  the 
comparison  desired  by  the  Army  between  the  IBM  and  Honeywell  computers. 
The  advantage  to  alternative  A  was  that  we  would  produce  a  model  which 
could  be  validated  in  detail,  thus  demonstrating  the  effectiveness  of 
our  methodology.  We  did  not  have  the  time  to  produce  three  models  so 
alternative  G  was  also  rejected.  Instead,  we  concentrated  on  getting  a 
much  data  as  possible  from  a  S1DPKKS  cycle  running  on  a  160/30. 

Section  4  details  our  data  collection  activities  for  the  S1DPF.RS 
Basic  Cycle.  The  next  sect  ion  presents  ir  approach  to  modeling  hard¬ 
ware/software  systems  for  performance  evaluation,  ranking  and  selection 


3.  Tlli:  IPSS  A  I’ PI,!  (.'A  IION  PROCESSING  system  methodology  (japs) 


3.1  THE  TAPS  MODELING  PERSPECTIVE 

The  problem  addressed  in  this  reserach  is  the  design  and 
implementation  of  a  model  building  methodology  to  assist  in  the 
evaluation  of  computer  hardware/software  systems.  The  goal  is  a 
methodology  with  the  widest  possible  .applicability  to  the  user 
community.  Therefore,  the  IPSS  design  goals  have  been  adopted, 
name  I y : 

1.  breadth  of_  Applicability  —  the  ability  to  model  the 
behavior  of  contemporary  and  forseeable  system 
architectures  and  operating  environments; 

2.  Functional  View  of  Systems  —  the  ability  to  identify  and 
characterize  system  components  and  activities  based  on 
their  function,  independent  of  a  particular  architecture 
or  environment; 

3.  Top  Down,  Modular  Model  Synthesis  —  the  ability  to  model 
to  a  level  of  detail  commensurate  with  research  objectives; 

4.  Expandable  S  t  r  ue t ure  —  the  capability  to  incorporate  new, 
higher  level  descriptive  facilities  and  performance  measures 
into  the  methodology  and  simulation  system;  and 

5.  Flexibility  of  Use  —  the  ability  to  be  used  by  a  wide 
spectrum  of  modelers  from  the  experienced  system  analyst/ 
designer  and  researcher  to  the  pr  ctitioner  and  student. 


Because  of  the  wide  range  of  knowledge  required  for  modeling 
computer  systems,  the  I  APS  methodology  reported  in  this  research 
dist inguishes  four  distinct  modeling  functions  and  provides  facilities 
and  tools  lor  each.  These  functions  partition  the  modeling  and  evalu¬ 
ation  of  computer  hardware/sof tware  systems  into  a  set  of  activities 
to  be  performed  by: 

1.  the  User, 

2.  the  Modeler, 

3.  the  Simulator,  and 

4.  the  IPSS  Analyst. 

These  activities  are  summarized  in  Figure  3-1.  As  shown,  the  Modeler 
is  responsible  for  the  creation  and  maintenance  of  model  libraries, 
the  User  for  the  selection  of  library  members  to  synthesize  a  model, 
the  Simulator  and  IPSS  Analyst  for  maintaining  IPSS  source  code  and 
execution  facilities.  We  now  define  these  job  functions  in  more 
detail . 

User  -  that  person  or  persons  whose  responsibility  is  the  evaluation 
of  computer  hardware/software  systems.  The  user  conducts 
modeling  experiments  by  selecting  pre-defined  model  components 
from  a  model  library,  and  selects  execution  options.  The  user 
validates  the  model,  analyzes  the  simulation  results  and 
pi'i  l  Mims  tin'  required  evaluation. 

Modeler  I  lial  pet  sou  or  persons  whose  primary  concern  is  with  tin' 

application  system  to  be  modeled  and  with  the  hardware  environ¬ 
ment  on  which  it  will  execute.  The  modeler  builds  and  maintains 


the  model  library  of  software  and  hardware  components.  The 
modeler  is  not  concerned  with  the  structure  or  execution  of  the 


IPSS  mode],  but  is  concerned  with  model  verification. 

Simulator  -  that  person  or  persons  whose  primary  concern  is  with  the 

structure  and  execution  of  the  IAPS  model.  The  Simulator  codes 
user-required  special-purpose  IPSS  routines,  incorporates  these 
routines  into  the  model,  and  verifies  their  correctness. 

IPSS  Analyst  -  that  person  or  persons  who  have  a  detailed  knowledge 
of  the  inner  workings  of  the  IPSS  simulator.  This  includes 
the  source  language  translation  process,  the  simulation  driver, 
facility  definitions  and  tables. 

User  level  activities  were  established  so  that  model  synthesis 
and  experimentation  could  be  easily  accomplished.  Hardware  charac¬ 
terization  and  workloads  can  be  changed  by  the  User  without  any  change 
to  the  IPSS  model  itself.  This  approach  assumes  a  library  of  computer 
system  characterizations.  Our  research  is  the  first  step  in  providing 
an  IPSS  system  library  for  the  User. 

The  role  of  the  User  is  distinct  from  that  of  the  Modeler, 
Simulator  and  IPSS  Analyst;  the  major  distinction  is  that  the  User 
produces  no  IPSS  source  code  or  workload  characterizat ions .  The 
Modeler  and  Simulator  may  be  the  same  person  or  persons.  They  must 
coordinate  their  activities  so  that  the  resulting  simulation  can  be 
validated.  For  example,  the  Modeler  describes  computer  hardware  using 
ll’SS  statements,  but  it  is  the  Simulator  who  describes  the  sequences 
of  the  IPSS  simulator's  acquisition,  use  and  release  of  this  hardware. 


i 
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The  Modeler,  Simulator  and  IPSS  Analyst  each  share  a  common  set 
of  modeling  activities.  As  summarized  in  Table  3-1,  these  activities 
are:  Hardware  characterization,  software  description,  sequence  of 

activities,  data  description  and  model  verification.  As  shown  in  the 
Table,  the  Modeler's  role  is  independent  oi  any  procedure  oriented  code. 
The  Simulator  has  Liu.'  responsibility  for  maintaining  the  I  Al’S  source 
code,  and  relies  on  the  IPSS  Analyst  for  special  functions  or 
requ i rements . 

The  remainder  of  this  section  is  organized  as  follows.  Section 
3.2  outlines  the  User  activities.  Section  3.3  presents  the  Modeler 
view,  Section  3.4  discusses  the  Simulator  view  and  relates  it  to  the 
Modeler.  The  IPSS  Analyst  function  is  presented  in  Section  3.5. 

3.2  THE  LAPS  MODELING  APPROACH:  THE  USER'S  ROLE 

The  user  is  defined  to  be  that  person  or  persons  with  overall 
computer  system  evaluation  responsibility  for  a  given  project.  As  shown 
in  Figure  3-2,  the  user  accepts  and  clarifies  a  set  of  evaluation 
requirements  and  produces  evaluation  documentation  through: 
o  interaction  with  the  Modeler  function, 
o  interactive  model  synthesis, 
o  validation  of  model  results,  and 

o  analysis  and  evaluation  of  computer  hardware/software  systems. 

The  User  interacts  with  the  Modeler  in  order  to  ensure  that  the  desired 
model  library  members  are  present  for  the  model  synthesis  phase.  The 
Modeler  may  he  required  to  change  the  existing  library  members,  add 


new  ones,  or  to  add  capabilities  to  the  TPSS  model  itself  (such  as  DBMS 
processing)  in  order  to  satisfy  the  User's  modeling  requirements. 


Table  3-1.  Modeling  Activities 


Requirements 
for  the 
Modeler 


Interactive 

Model 

Synthesis 


Validation, 
Analysis , 
Evaluation 


igure  3-2.  User's  Rcvle  in  the  IAPS  Methodology 
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The  next  step  in  the  User  process  is  interactive  model  synthesis. 
This  produces  an  execution-ready  model  through  the  selection  of 
a  priori  defined  model  components  from  the  model  library.  This 
process  is  illustrated  in  Figure  3-3.  We  have  implemented  interactive 
model  synthesis,  and  used  it  to  produce  the  results  reported  in  this 
research.  An  example  of  the  User-computer  interaction  sequence  is 
presented  in  Figure  3-4. 

We  designed,  but  did  not  implement  (due  to  lack  of  time)  a  more 
elaborate  model  synthesis  procedure  which  would  allow  the  user  to 
modify  some  of  the  existing  library  members  in  order  to  tailor  t hem 
for  specific  processing  needs.  As  shown  in  Figure  3-5,  we  envision 
that  the  software  processing  and  data  base  description  members  of  the 
model  library  could  be  so  tailored.  This  would  require  more  user 
interaction  than  now  required  but  would  enhance  flexibility.  This 
approach  is  further  discussed  in  Section  9. 

3.3  THE  IAPS  MODELER  VIEW  OF  COMPUTER  HARDWARE/SOFTWARE  SYSTEMS 

Figure  3-6  shows  that  the  Modeler's  responsibilities  include 
the  preparation  of  data  for  input  to  the  model,  and  the  verification 
of  resultant  simulation  statistics.  Input  data  preparation  involves 
the  following: 

1.  Description  ol  the  system  hardware, 

2.  Description  of  the  applicaiton  processing  workload 

3.  Description  of  the  characteristics  of  the  data  files  used 
by  the  application,  and 


4.  Representing  these  descriptions  according  to  the  IAPS  method¬ 
ology  specifications  and  storing  them  in  the  IAPS  model  library. 


2] 
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Note*  Underlined  entries  are  User  input  or  response. 


Figure  3-4.  Example  of  Interactive  Model  Synthesis 


An  overview  of  these  Modeler  activities  is  now  presented.  Details 
are  found  in  the  Appendices  as  noted  in  the  text. 

Description  of  System  Hardware 

The  Modeler  is  responsible  for  identifying  the  basic  types  of 
computer  devices  for  the  system  being  modeled.  As  shown  in  Table  !-?  , 
t  he  devices  primarily  reflect  the  computer's  mainframe  and  secondary 
storage  subsystem,  for  each  device  identified,  the  modeler  provides 
a  detailed  functional  specification  which  indicates  capacity,  speed, 
and  special  features.  A  list  of  the  type  of  data  collected  for 
disk,  drum,  tape,  and  unit  record  devices  is  given  in  Table  3-3. 

This  type  of  data  is  usually  readily  available  in  vendor's  technical 
system  reference  manuals.  The  Modeler  then  encodes  this  data  into  IPSS 
statements  in  a  straight-forward  way.  Examples  of  these  IPSS  statements 
•  ire  found  in  Appendix  II. 

1  )cLs_l ' ri pjt_l o 1 >_  of  App  1  i cat  i on  Processing  Characteristics 

The  application  workload  and  its  data  files  are  characterized  by 
two  types  of  tables  which  are  prepared  by  the  modeler.  These  tables 
are  called  the  Application  File  Table  (AF  Table),  and  the  Application 
Processing  Table  (AP  Table).  The  Application  File  Table  gives 
detailed  information  about  the  files  being  processed  from  the  application 
program  point  of  view.  The  Application  Processing  Table  gives,  in 
outline  fashion,  a  step  by  step  description  of  application  processing. 

The  Application  File  Table  (AF  Table) 

The  AF  Table  describes  the  characteristics  of  files  as  known  by 
the  application  program.  Each  entry  in  this  table  describes  a  single 
file  and  contains:  a  file-identifier,  the  logical  record  length  and 
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Table  3-2.  Modeler  Checklist  for  Computer  System  Hardware 


Device  Type 
CPU 

Main  memory,  cache 
Channels  (multiplexor,  selector) 
Disk  Units,  Disk  Controller 
Tape  Units,  Tape  Controller 
Drum  Units,  Drum  Controller 

Operator's  Console 
Line  Printer 
Card  Reader 
Card  Punch 


Table  3-3.  IPSS  Data  Required  to  Model  I/O  Devices 


Disk,  Drum  number  of  packs  per  control  unit 


number  of  cylinders  per  pack 
number  of  tracks  per  cylinder 
maximum  track  capacity 

maximum  block  size  allowable  for  the  devic 
rotational  speed 
data  transfer  rate 
cylinder  access  times 

Tape  number  of  tape  units  per  control  unit 

tape  recording  density 
tape  speed  (reading/writing) 
inter-block  gap  size 

maximum  block  size  recorded  on  the  tape 
tape  start-stop  time 
forward  erase  length 
rewind  rate 

Unit  Record 
(Card  reader, 
punch , 
operator '  s 
console, etc. ) 


maximum  block  size 
transmission  mode 
transmission  rate 
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block  size,  and  the  number  of  records  processed.  An  example  is 
given  in  Figure  3-7.  This  example  shows  two  files,  one  an  unblocked 
card-image  file  of  554  records  which  is  identified  through  the  comment 
as  SIDPERS  file  COOAAC.  The  other  file,  C1CAAC,  contains  987  506-byte 
records.  Note  that  the  block  size  specified  in  the  AF  Table  is  the 
unit  of  I/O  for  the  application  program  and  need  not  represent  the 
secondary  storage  block  size. 

The  Application  Processing  Table  (AP  Table) 

The  AP  Table  mimics  the  I/O  processing  done  by  an  application 
program.  Each  table  entry  consists  of  two  records,  first  a  processing 
specification  record,  followed  immediately  by  a  processing  definition 
record . 

The  specification  record  identifies  the  type  of  processing, 

(0  for  any  delay  due  to  the  operator,  I  for  input,  P  for  CPU  activity, 
and  0  for  output).  The  "D"  definition  record  quantifies  the  delay; 
the  "I"  and  "0"  definition  records  specify:  the  file,  a  concurrency 
index,  random  or  sequential  processing,  and  percentage  of  file  processed; 
and  the  "P"  definition  record  specifies  the  type  of  activity  engaged  in 
by  the  application  program,  such  as  EDIT,  SORT,  or  REPORT. 

Figure  3-8  depicts  a  typical  example  of  a  job  step  (for  example, 
SIDPERS).  First,  there  is  a  delay  of  10  to  15  seconds  due  to  operator 
responses  to  console  messages,  or  tape  mounts.  Then  all  of  file  01,  and 
507.  of  file  10  are  read  concurrently,  file  01  sequentially  and  file  10 
randomly;  one  of  the  files  is  edited,  and  the  output  is  sent  to  file  04. 
Finally,  57  of  file  10  is  rewritten  after  all  other  processing  is 
complete.  Note  that  the  order  of  application  record  processing  is 
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File 

id 

I.Rec  1 

Block 

Si2e 

II 

Records 

Commen  t  s 

01 

80 

80 

554 

Card  Image 

Input  - 

C00AAC 

10 

506 
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987 

Edit  Table 

File  - 

C1CAAC 

Figure  3-7.  An  Example  of  the  Application  File  Table 
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* 

* 

* 

* 

* 

* 

* 

* 


A  Typical  Jobs cep  in  SIDPEHS 


1000. 

15000.  1.0 

TAPE  MOUNT 

01 

X 

S 

100. 

COOAAC 

10 

X 

R 

50. 

C1CAAC 

X 

EDIT 

CPU  PROCESSING 

.04 

X 

S 

100. 

B1AAAC 

10 

Y 

R 

10. 

C1CAAC 

Figure  3-8.  An  Example  of  the  Application  Processing  Table 


*  .  -  1  — 
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determined  by  the  concurrency  indicator  (the  "X"  and  "Y"  in  Figure  3-8). 
The  "X"  indicates  that  files  01,  10  and  04  are  processed  concurrently, 
(i.e.,  read  one  record  of  file  01,  one  of  file  10,  write  one  to  file 
04,  then  repeat  until  all  three  files  are  exhausted).  The  "V"  ot  Fig, ure 
3-8  indicates  that  file  10  is  written  after  the  comp  1  etc  processing 
of  files  01,  10,  and  04.  (Any  alphanumeric  characters,  except  blank, 
may  be  used  as  a  concurrency  indicator).  As  also  shown  in  this  figure, 
comments  may  appear  on  the  right  hand  side  of  any  data  card,  and  on 
any  "comment"  card  (which  is  designated  by  an  asterick  in  the  first 
c  o 1 umn ) . 

Description  of  Database  Characteristics 

The  term  database  is  used  here  to  mean  the  data  files  managed  by 
the  hardware  system's  data  files.  Those  files  required  by  an  application 
must  be  characterized  by  the  Modeler  and  the  results  placed  in  the  System 
File  Table. 

In  this  table,  each  record  gives  secondary  storage  information 
about  a  single  file.  Each  file  is  assigned  a  volume  type  (disk,  tape, 
or  console)  and  a  volume  number.  The  logical  record  length,  blocksize, 
and  file  size  (number  of  logical  records)  are  recorded.  Disk  file 
information  includes  the  extent  type  (index  (I),  primary  (P) ,  or 
overflow  (0))  the  percentage  of  records  on  the  primary  extent  (%PE) , 
the  number  of  secondary  extents  (// SE) .  If  the  file  placement  is  known, 
it  is  given  in  terms  of  low  and  high  cylinder  and  track  addresses. 

(If  unknown  for  disk  files  (U) ,  the  file  is  placed  randomly  on  the 
volume  during  [APS  simulation).  Finally  a  comment  field  is  provided 
as  an  aid  to  the  modeler.  Provision  is  made  to  define  VTOC  files  (V), 


sort  work  files,  and  messages  to  and  from  an  operator’s  console. 

For  detailed  formatting  information,  see  Appendix  F. 

The  examples  in  !-(  are  typical.  System  file  01  has  554  unblocked 
records  with  an  LRECL  of  80.  It  resides  on  tape  unit  T01  with  an  LRECL 
and  blocksize  of  80,  and  an  "unknown"  placement  (U)  ,  which  for  tape 
files  means  that  the  file  begins  at  the  beginning  of  -the  reel.  Note 
that  the  modeler  has  used  comments  to  identify  the  file  as  C00AAC  -card 
image  input.  User  file  10  (the  third  line  of  Table  3-9),  is  also 

unblocked  with  an  LRECL  of  506;  it  has  987  records  in  its  prime  extent  (P) , 

which  resides  on  disk  unit  D03,  with  allocated  space  from  cylinder  153 

track  0,  to  cylinder  170,  track  19.  This  file  is  an  ISAM  file  and  thus 

has  an  index  extent  which  resides  on  disk  unit  D02 ,  giving  among  other 
things,  its  known  placement. 

3.4  THE  IAPS  SIMULATOR  VIEW 

The  IPSS  Simulator  function  requires  a  person  or  persons  who 
are  knowledgeable  programmers  and  analysts  of  the  IPSS  language  and 
execution  facilities.  The  basic  simulator  role  is  to  augment  the  IPSS 
model  structure  we  have  provided  in  order  to  be  responsive  to  changing 
Modeler  requirements. 

A  Simulator  overview  of  the  TAPS  methodology  is  given  in  Figure 
3-10.  This  figure  shows  the  interaction  among  three  components  of  IPSS: 

The  Exogenous  Event  Stream  Component.  The  IPSS  Define  Model  Component 
is  represented  by  the  Equates  between  the  two  latter  components. 

We  have  completed  the  simulator  function  for  the  present  IAPS 
methodology.  A  large  class  of  computer  systems  can  be  simulated  and 
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Figure  3-10.  Overview  of  the  Service  Hierarchy  in  the  IPSS  Model 
The  Simulator's  View  of  the  IAPS  Methodology 
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evaluated  without  any  further  Simulator  activity.  The  Simulator  is 
required  if  a  system  outside  the  scope  of  the  present  IAPS  is  to  be 
modeled.  Kxamples  of  such  systems  are:  Database  management  systems, 
teleprocessing,  distributed  systems  and  opcr..t  inc  system  task  management  . 


3.S  Till;  !!>SS  ANA!. VST  VI  KW  Of  COMIVTKIl  SYSTKMS 

The  IPSS  Analyst  is  a  specialist  in  the  1PSS  Modeling  and 
Kxecution  fai'ilities  (see  Appendix  A).  The  IPSS  Analyst  view  of  the 
simulation  process  is  represented  in  Figure  1-11.  This  role  requires 
a  knowledge  of  the  details  of  the  IPSS  translation  process,  the  simulation 
nucleus,  and  facility  definition  tables.  The  need  for  the  IPSS  Analyst 
will  be  further  reduced  over  time  as  IPSS  evolves  into  a  more  fully 
developed  product.  We  required  the  type  of  knowledge  represented  by 
the  IPSS  Analyst  role  only  a  few  times  during  the  course  of  our  project. 
Kxamples  of  what  we  required  (and  easily  ascertained  through  source 
listings)  were  IPSS  statement  options,  random  number  generation 
algorithms,  and  facility  table  value  offsets. 
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4.  MODELING  SIDPERS  USING  IAPS 

4.1  SELECTION  OF  A  SIDPERS  SUBSET 

SIDPERS  is  ;i  standard,  automated  integrated  personnel  system 
designed  to  provide  personnel  information  systems  support  at  division, 
installation,  brigade,  battalion  and  unit  levels  (S1D76).  ETDPERS 
pet  forms  four  major  functions  in  support  of  Active  Army  personnel 
and  organizations: 

1.  Strength  accounting, 

2.  Organization  and  personnel  recordkeeping, 

3.  Information  exchange  with  other  automated  systems,  and 

4.  Command  and  staff  reporting. 

A  SIDPERS  activity  is  designed  to  support  a  data  base  of  computer 
files  for  up  to  50,000  personnel  and  1,000  organizations. 

SIDPERS  software  consists  of  five  DOS-E  jobs: 
o  AACR01  -  Labels  and  Assignments 
o  AACR02  -  SIDPERS  Basic  Cycle 
o  AACR03  -  SIRCUS 
o  AACR04  -  SIDPERS  Back-up  Cycle 
o  AACR05  -  SIDPERS  Recovery  Cycle 

The  focus  of  our  project  was  on  the  SIDPERS  Basic  Cycle, 

.lob  AACR02.  This  job  consists  of  19  job  steps  which  proceed  from 
editing  functions,  through  file  update,  to  reporting.  Since  the  project 
duration  and  objectives  did  not  permit  the  modeling  and  evaluation  of 
all  of  SIDPERS,  a  sunset  of  programs  was  selected  with  the  assistance 
of  USACSC  Quality  Assurance  personnel  (WHI79). 
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Tiu‘  editing  programs,  two  of  the  master  lilt-  update  programs  aiul 
one  report  preparation  program  were  selected  from  all  the  programs  in 
the  STDPERS  basic  cycle.  Each  editing  program  was  a  single  job  step 
and  thus  some  validation  data  could  be  obtained.  The  selected  update 
and  report  preparation  programs  were,  however,  single  phases  loaded 
and  executed  dynamically  as  part  of  a  larger  job  step.  While  the 
modeling  of  the  logic  of  those  programs  was  not  a  problem,  obtaining 
validation  data  for  these  phases  was  not  possible.  In  addition,  the 
modeling  of  the  entire  job  step  in  which  these  phases  were  located 
would  bo  almost  as  dill icull,  again,  for  lack  of  adequate  validation 
data.  Thus,  the  selected  update  and  report  preparation  programs  were 
not  modeled. 

The  programs  we  modeled  represent  transaction  classification, 
sorting,  and  validity  editing;  and  incorporate  concurrent  direct  and 
sequential  access  to  disk  files  and  sequential  access  to  tape  files. 
These  programs  are: 

P1AAACA  -  transaction  classification  and  scheduling, 

P1BAACS  -  transaction  sort, 

P1CAAC  -  transaction  validity  editing,  and 

P1GAAA0S  -  sort  and  update  "queue"  production. 

For  convenience  and  readability,  these  programs  will  be  referred 
to  as  PlA,  P1B,  PIC,  and  PIG,  respectively. 

4.2  MODELING  THE  SIDPERS  SUBSET 

Once  this  subset  of  the  SIDPEKS  programs  was  identified,  we 
obtained  current  COBOL  source  listings,  the  DOS  version  of  the  SIDPERS 


Operations  aiul  S*  hcdu  I  i  ng  Manual  (.  S  I  1  >  / )  »  and  t  ho  SlIH’i.KS  Basic  Cycle 
.ICL  listing.  Wo  .m.i  1  v/.od  t  tn  so  souroos  in  order  lo  obtain  basin  file 
data  which  is  constant  to  any  SIDPERS  processing  cycle.  The  type  ot 
data  wo  obtained  wore  file  names,  type  of  file  (c.g.,  ISAM,  sequential), 
use  ot  tile  (input,  oupnt ,  both  input  and  output),  record  processing 
mode  (sequential  or  random) .  The  details  of  our  findings  arc  sunnari.'cl 
i  u  Ap vend  i  v.  C . 

No-. t,  wo  determined  that  the  data  wo  required  for  validating  a 
model  ol  StppIKS  was  ivailable  from  four  siuiroes,  name  I v : 

I  .  i  HAS  f’  Aoi  oun  f  i  ng  , 

2.  SYSl.lSf, 

).  Operator  Console  Log ,  and 

4.  DITTO  I'li  1  ity. 

The  typo  of  data  provided  by  each  of  these  sources  is  summarized  in 
Table  4-1. 

We  visited  the  Ft.  Stewart  Division  Data  Center  on  August  2nd  and 
Ird,  1979,  and  observed  the  computer  operat  ion  during  SIDPERS  Basic 
Cycle  process  i  ng,.  We  obtained  computer  list  ings  lor  the  data  sources 
listed  above.  Table  4-2  presents  a  summary  of  the  data  we  collected 
at  Ft.  Stewart  for  the  first  four  job  steps  of  the  SIDPERS  Basic  Cycle 
on  August  2,  1979,  and  indicates  the  source  of  the  data  items. 

The  following  is  a  discussion  of  these  data  sources  in  more  detail. 

GRASP 

GRASP  provides  a  wealth  of  accounting  data  which  is  extremely 
useful  in  validating  simulation  models.  For  completeness,  a  list  of  the 
type  of  data  available  through  GRASP  is  provided  in  Appendix  G. 


Table  4-1.  Sources  of  System  Data 


1.  GRASP  Step  Accounting 
CPU  time 

Wait  on  operator  time 
Job  duration  time 
Interference  duration  time 
I/O  wait  time 
I/O  device  usage  time 
Start  I/O  counts 

Time  waiting  for  and  using  the  LTA 
SYSRES  usage  time 
Channel  activity  time 

2 •  SYSLIST 

Gives  job  stop  start  and  stop  time 
Number  of  records  sorted 
Some  file  counts 

3.  Operator  Console  Log 

Number  and  length  of  console  messages 

4.  DITTO  Utility 


Record  counts 

Type  of  records  processed 
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Tabic  4-2.  2  August  1979  Ft.  Sti'w.irt  Record  Process i ng  lor  Programs 

P1A  Through  PIC 


File  Name 

Media 

Input/ 

Output 

Concurrently 

Processed 

with 

%  File 
Processed 

Number 

of 

Records 

Source  of 
Record 

Count  Data 

1 

j  PI  A 

'  COOAAC 

! 

Tape 

I 

100 

554 

Card  count 

1  B1AAAC 

i 

1 

! 

Tape 

I 

100 

2111 

B1AAAC  out 
+  31  Grade 
Changes 

|  COOAAC 

I 

Tape 

L 

100 

661 

Tape  DITTO 

|  A1AAAC 

Tape 

0 

100 

1249 

SYSLIST 

sort  count 

in  PI B 

K1AAAC 

Tape 

0 

100 

1171 

Tape  DITTO 

B1AAAC 

Tape 

0 

100 

2080 

Tape  DITTO 

C1CAAC 

Disk 

I/O 

987 

Program 
source  and  If 
t  rans jc t i ons 

XIFTAAC 
(X=A, B,C, 
K.F.G.H) 

Disk 

I 

0 

Program 

source 

1 i s  t i ng 

P1B 

A1AAAC 

Tape 

I 

100 

1249 

SYSLIST 

B1AAAC 

Tape 

I 

0 

- 

Monthly 

only 

C1CAAC 

Disk 

I/O 

.3 

987 

A 1 BAAC 

Tape 

0 

100 

1249 

SYSLIST 

B1AAAC 

Tape 

0 

0 

- 

(see  above) 

S0RTWK1 -3 


Disk 


1/0 


Computed 
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Table  4-2  Continued . 


Concurrently 

Number 

Source  of 

Input / 

Processed 

%  File 

of 

Record 

File  Name 

Media 

Output 

with 

Processed 

Records 

Count  Data 

PIC 

A1BAAC 

Tape 

I 

100 

1249 

SYSLIST 

C1CAAC 

Disk 

I/O 

125 

987 

Source 
program  and 
input 

transactions 

A1CAAC 

Tape 

0 

100 

1249 

SVSL1ST 

PIC 

A1CAAC 

Tape 

I 

100 

1249 

SYSLIST 

R1GAAC 

Tape 

I 

100 

50 

C1CAAC 

Disk 

I/O 

987 

S0RTWK1-6 

Disk 

I/O 

Computed 

X1GAAC 

Disk 

0 

(A)  0 

- 

SYSLIST 

(X-A.B.C, 

(B)  0 

- 

SYSLIST 

E ,  F ,  G ,  I ,  J , 

(C)  100 

30 

SYSLIST 

K.M.N.Q.R) 

(E)  100 

1210 

SYSLIST 

(F)  100 

7 

SYSLIST 

(G)  0 

- 

SYSLIST 

O)  0 

- 

SYSLIST 

(.1)  0 

- 

SYSi.l  ST 

(lO  100 

;> 

SYSLIST 

(M)  O 

- 

SYSLIST 

(N)  0 

- 

SYSLI ST 

(Q)  0 

- 

SYSLIST 

(R)  0 

- 

SYSLIST 

GRASP,  however,  w.is  of  limited  use  to  us  sinre  i:UASI’  step  accoun¬ 
ting  was  not  available  at  the  Ft.  Steward  Division  Data  Center.  Table 
4-1  summarizes  the  data  we  obtained  from  GRASP  for  the  August  2,  1479, 
execution  of  the  SIDPKRS  Basie  Cycle.  As  shown  in  this  table,  GRASP 
job  accounting  statistics  did  not  provide  us  with  any  useful  data  for 
programs  P1A  through  PIC.  Since  the  cycle  we  observed  was  initially 
cancelled  in  program  PIG,  we  were  able  to  use  the  GRASP  CPU  time  of 
approximately  twelve  minutes  as  an  estimate  of  the  complete  P1A  through 
PIC  CPU  time. 

SYSI.l  ST 

SYSL1ST  was  of  value  in  determining  file  record  counts  only  when 
the  job  contained  a  sort.  Program  P1B  and  PIG  sort  entire  files  and 
the  number  of  records  sorted  is  reported  on  the  SYSLTST. 

Operator  Console 

The  operator  console  log  did  not  provide  us  with  any  data  on  the 
number  of  records  processed.  However,  we  observed  that,  because  of  the 
amount  of  time  spent  displaying  and  responding  to  messages,  the  operator's 
console  was  a  more  important  element  in  the  system  from  a  performance 
perspective  than  we  originally  anticipated. 

Tape  DITTO 

By  far  the  most  useful  method  of  determining  the  number  of  records 
processed  on  a  per  file  basis  is  the  Tape  Utility  DTTTO.  This  utility 
simply  lists  the  entire  file,  allowing  not  only  an  accurate  count 
but  also  insights  into  the  types  of  data  being  processed.  We  obtained 
DITTO  listings  of  the  transaction  input  files  and  the  stacker  files. 
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Table  4-3.  SIDPERS  Basic  CycLc,  2  August  1979,  Ft.  Stewart  (Extracted 
from  GRASP  Accounting  Reports) 


Activity 

Complete 
Cyc  le 

P1A  through 

PIG  cancel 

P1A  through 

PIG  complete 

Elapsed  time 

4/33/27 

38/54 

17/50** 

Non-MPS  time 

4/25/23* 

38/53 

N/A 

CPU  t  ime 

2/36/12 

11/56 

N/A 

Pages  spooled 

165 

11 

N/A 

Pages  loaded 

4443 

363 

N/A 

Transient  Area  time 
Wait 

Use 

10 

1/15/34 

0 

26/05 

N/A 

N/A 

RES  I/O 

31622 

1893 

N/A 

Operator  console 
t  ime 

42/28 

23/10 

1 

2/27***  j 

I 

..  .  ] 

Does  not  include  07/11  restart 

time 

1 

i 

**  from  SYSLIST 

i 

***  from  Console  log 
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MODKI.I.MC  TWO  COMPl'TFK  IIARDWARK  AKCII I TKOITIKKS  IN  l/M’S 
..I  1  1'SS  IIAKDWAR1-:  I'llAlvAdT.R  I  /AT  I  ON 

This  section  discusses  the  modeling  of  the  IBM  U>0  Model  TO 
computer  (CS^)  and  the  Honeywell  Series  60  Level  6  Model  47  minicomputer 
(DAS^)  systems.  A  computer  architecture  is  typically  represented  in 
tl’SS  bv  characterizing  the  following: 

1.  the  hardware  devices,  their  capacities  and  processing 
characteristics, 

2.  the  interconnections  among  the  hardware  devices,  and 

1.  t  lie  operal  ing  system. 

Hardware  Dev  ices,  Cap.ic  i  t  ies_,  and  Processing  Characteristics 

The  block  diagram  for  the  two  modeled  systems  are  shown  in 
Figure  5-'  and  5-2.  The  connecting  edges  between  primary  and  secondary 
storage  represent  the  paths  along  which  data  is  transferred.  Note 
that  in  the  360/J0,  the  dual  channel  tape  controller  allows  either 
channel  1  or  channel  2  to  complete  an  1/0  request.  Thus,  there 
are  two  paths  to  the  tape  units  and  one  to  the  disk.  We  assume 
that  channel  1  will  be  used  to  access  a  tape  unit  when  channel 
2  is  busy. 

The  focal  point  of  the  I PSS  modeling  of  these  systems  is  on 
the  secondary  storage  subsystem.  We  examined  technical  specifications 
provided  by  the  respective  vendors  and  extracted  performance  charac¬ 
teristics  and  capacities  for  both  the  direct  access  storage  devices 
and  the  magnetic  tape  units.  These  characteristics  are  reported 
in  Tables  5-1  and  5-.’  respectively.  This  data  was  incorporated  into 


2401-2  Tape  Drives 


Figure?  5  1.  Typical  CS^  Hardware  Configuration 


Figure  5-2.  Honeywell  Level  6  Architecture  -  DAS _ 
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Table  5-1.  Direct  Access  Storage  Devices 


Disk  Units  ~j 

Physical  Characteristics 

IBM 

2314A 

IBM 

3330 

Honeywell  ! 

MSU  9102/9106 

Drives  per  unit 

8 

8 

3 

Bytes  per  unit 

233. 4M 

800M 

201M  1 

< 

i 

Speed 

i 

Average  Seek 

60  ms 

30  ms 

30  ms 

Average  Rotational  Delay 

12.5  ms  8.4  ms 

8.33  ms 

Data  rate  (kilobytes  per 
second ) 

312 

806 

1,200 

Capacity 

Cylinders  per  pack 

200 

404 

CO 

Tracks  per  cylinder 

20 

19 

5 

Tracks  per  pack 

4,000 

7,676 

4,115 

Bytes  per  track 

7,294 

13,030 

16,384* 

Bytes  per  cylinder 

145,880 

247,570 

81,920 

Bytes  per  pack 

29.18M 

100M 

67M 

*Based  on  64.256  byte-sectors 

per  track 

Table  5-2. 


Magnetic  Tape  Units* 


Physical  Characteristics 
Drives 
Tracks 
Density 

Inter-block  gap  (inches) 
Block  length 

Sjieed 

Read/write  (inches  per  second) 

Rewind  rate  (inches  per 
second) 

Data  transfer  rate  (bytes  per 
second) 

Start /stop  time 


*Where  more  than  one  characteristic 
included  in  the  model (s). 


Tape  Units 

IBM 

2400-1 
Model  5 

Honeywell 
MTU  9109 

Honeywe] 1 
MTU  9110 

6 

2 

6 

9 

9 

9 

800/1600 

800/1600 

800/1600 

.6 

.6 

.6 

_ 

2048 

_ 

75 

45 

75 

350 

200 

250 

120k 

36k/72k 

6 0k /120k 

13  ms . 

8.33  ms 

5  ms 

is  listed,  the  underlined  number  was 


IPSS  models  through  IPSS  hardware-facility  statements.  A  sample 
of  these  statements  is  given  in  Appendix  B. 

Interconnections  Among  Hardware  Devices  in  IPSS 

In  the  IPSS  System  Resources  component,  device  characteristics 
are  associated  with  an  access  mechanism  and  volume.  However, 
channels,  control  units,  and  the  CPU  are  independent,  unrelated 
facilities.  These  facilities  are  interrelated  in  IPSS  models  by 
a  service  which  represents  a  channel  program.  This  service,  usually 
called  Cl  I  PGM ,  is  almost  a  standard  part  of  every  IPSS  model  and 
plays  a  central  part  in  the  IAPS  methodology.  Its  function  is  to 
generate  a  physical  (device)  address  and  to  seize,  use  and  release 
all  the  facilities  (e.g.,  CPU,  channel  controller,  access  mechanism, 
volume)  in  the  path  from  the  CPU  to  the  secondary  storage  device  in 
order  to  simulate  a  data  transfer.  The  IPSS  CHPGM  service  is  listed 
in  Appendix  B. 

Operating  System  Representation  in  IPSS 

In  IPSS,  an  operating  system  is  represented  by  one  or  more  services 
which  simulate  job  scheduling,  task  management  and  resource  allocation 
activities.  We  investigated  but  did  not  represent  the  operating 
system  functions  in  either  the  IBM  or  the  Honeywell  model.  The  reason  is 
that  we  did  not  have  time  to  analyze  these  function,  or  model  them,  in 
sufficient  detail  to  warrant  their  inclusion  in  the  models. 

However,  our  investigation  revealed  that  the  IBM  360  Model  30 
supports  a  Disk  Operating  System  (DOS)  with  the  following  major  support 
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o  CRASH  ,hv('iiiU  ini;  package, 
o  DYNAM/T  tape  in. inap.o  r  , 
ii  ADAS  disk  nuiw^LT,  and 
o  SYNCSORT  sort  package. 

We  attempted  to  ascertain  how  these  packages  interact  with 
DOS  and  under  what  conditions  they  request  1/0.  The  next  step 
would  have  been  to  represent  processing,  resource  allocation,  I/O 
characteristics,  and  dispatching  of  each  of  these  packages  (including 
DOS)  in  one  or  more  IPSS  Endogenous  Services.  Following  this, 
we  would  include  these  services  at  the  appropriate  place  in  the 
IPSS  model  (i.e.,  at  the  LNTK  service),  then  verify  and  validate 
the  resulting  model. 

5.2  ARCHITECTURAL  VARIATIONS 

For  convenience  in  referencing  the  hardware  systems  that  we 
modeled,  we  designated  the  model  of  the  IBM  360  Model  30  as  Model  Al, 
and  will  refer  to  the  model  of  the  Honeywell  Level  6  minicomputer  as 
model  111.  In  addition,  we  considered  three  variations  of  model  Al 
and  one  variation  of  model  B1  in  order  to  demonstrate  the  capabilities 
of  IPSS  and  the  I APS  methodology. 

As  shown  in  Table  5-3,  the  variations  on  model  Al  are  the 
replacement  of  the  2314  disk  unit  with  a  3330  disk  unit  (A2)  ,  the 
replacement  of  the  14  character  per  second  operator  console  with  a 
'160  character  per  second  console  (A3),  and  both  of  the  above  replace¬ 
ments  (A4) .  These  experiments  were  designed  based  on  observations 


of  the  current  360  Model  30. 
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Table  5-3.  Hardware  Differences 


Model  Designation 


Al 


A2 


A3 


A4 


Summary  of  Architecture  Differences 

Standard  360  Model  30 

o  14  characters  per  second  operator 
console 

o  2314  direct  access  storage  facility 

360  Model  30 

o  14  characters  per  second  operator 
console 

o  3330  direct  access  storage  facility 

360  Model  30 

o  960  characters  per  second  operator 
console 

o  2314  direct  access  storage  facility 

360  Model  30 

o  960  characters  per  second  operator 
console 

o  3330  direct  access  storage  facility 


Tabic  5-3  Continued. 


i  Model  Designation 

t>  1 


Summary  of  Architecture  Differences 
Standard  Honeywell  Level  6  Model  47 


o  6  MSU9106  disk  drives 


o  (>  MTU 91  10  tape  drives 

R2  Honeywell  Level  6  Model  47 

o  3  MSU9106  disk  drives 
o  2  MTU9109  tape  drives 


All  17)0  Model  30  architectures  had  six  2400-1  Model  5  tape  drives. 
All  Honeywell  Level  6  Model  47  architectures  had  a  960  character 
per  second  operator  console. 


The  variation  on  model  BI  was  the  deletion  of  three  disk 


drives  and  the  replacement  of  the  6  MTU  9110  tape  units  with  2 
MTU  9109  tape  units. 

Table  5-4  shows  the  performance  characteristics  of  these 
architectural  variations  relative  to  model  A1  (the  standard  360 
Model  30).  Model  Bl  is  clearly  superior  to  A1  in  every  way  except 
tape  concurrency  (each  has  six  tape  drives),  and  all  the  variations 
show  at  least  one  area  of  superiority. 
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Table  5-4.  Performance  Characteristics  of  Alternate  Hardware 
Architectures  Relative  to  Model  A1  (Standard  560 
Modi' 1  10) 


Performance  Character ist  ir 

Mod 

el  Designation 

' 

A1 

A2 

A  5 

A4 

B1 

_«A_  l 

Capacity 

] 

i 

Oisk  (bvtes) 

1 

1.4 

1 

1.4 

1.7 

Tape  (available  for 

1 

1 

i 

1 

1 

concurrent  use) 

Speed 

i 

Disk*  (I/O  per  unit  time) 

1 

2 

1 

2 

2 

2 

Tape**  (I/O  per  unit  time) 

1 

1 

1 

1 

2.5 

1  .4  | 

CPU  (Instructions  executed 

per  unit  time) 

1 

1 

1 

1 

7.5 

7’3 

Operator  Console  (Characters 

per  unit  time) 

1 

1 

68.6 

68.6 

68.6 

68.h 

_ J 

* Based  on  average  seek  and  average  rotational  delay  and  time  to 
transfer  one  100  byte  record 


**Based  on  time  to  transfer  one  100  byte  record  and  start/stop  time 


6.  OVERVIEW  OF  TAPS  MODEL  STRUCTURE  AND  EXECUTION 


An  TAPS  model  consists  of  a  collection  of  IPSS  service 
facilities  whose  invocation  sequence  is  hierarchial.  Figure  6-1 
depicts  the  relationships  among  the  services  and  indicates  their 
generic  function.  As  shown  in  the  Figure,  the  arrival  of  an  appli¬ 
cation  job  on  a  computer  is  represented  by  the  START  service. 

Several  different  applications  could  be  started  simultaneously  and, 
if  so,  would  compete  for  systems  resources  (such  as  the  operating 
system,  main  memory,  data  channels).  In  the  models  we  synthesized, 
only  one  application  was  started,  namely  SIDPERS.  The  START  service 
invokes  the  application  processing  service  APPL  and  waits  for  its 
completion.  The  APPL  service  determines  the  processing  required  for 
an  execution  group  (DOS  job  step),  invokes  the  EXGP  service  to  perform 
this  processing  and  waits  for  its  completion.  The  EXGP  service 
represents  the  processing  performed  by  a  user-determined  unit  of  work. 
This  service  is  driven  by  the  values  provided  by  the  RDGP  procedure. 

Its  main  functions  are  to  schedule  I/O  activities  to  data  files,  and 
to  represent  CPU  processing.  I/O  is  represented  by  an  invocation  of  the 
INTF  service  and  a  wait  for  response.  The  INTF  service  is  essentially 
a  null  routine  which  is  a  system  link  to  future  processing  activities 
(such  as  DBMS  or  the  operating  system).  Currently,  INTF  invokes  the 
FMAP  service  which  represents  the  mapping  of  the  application  Files 
to  specific  system  files  which  are  located  on  secondary  storage.  A 
single  application  I/O  request  to  FMAP  will  generate  one  or  m<>re 
requests  for  system  records.  FMAP  issues  a  request  for  a  system 


. 
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record  hv  invoking  t hr  BUFMR  service  and  then  waits  for  a  response. 

Hl’KMR  represents  t  lie  huf  1  er  management  function.  If  a  system  record 
is  in  one  of  the  buffers,  an  immediate  response  t  o  l'MAP  is  r.ener.ilei!, 
otherwise  the  CHPOM  service  is  invoked.  CH PGM  represents  channel 
program  processing:  it  uses  the  IPSS  data  base  structure  and  hardware 
facilities  to  generate  a  hardware  address,  computes  the  read /write 
time,  and  advances  the  simulator  clock  accordingly.  Table  6-1  relates 
the  IPSS  services  identified  in  Figure  6-1  to  the  corresponding 
SIDPK.RS  processing  activities. 

Model  Syntheses 

One  of  the  advantages  of  IPSS  in  general,  and  TAPS  in  particular, 
is  tiie  ease  of  synthesis  of  experiments.  Figure  6-2  outlines  our 
basic  approach  to  producing  models  with  different  hardware  architec¬ 
tures.  We  functionally  divided  the  IPSS  models  and  placed  the  parts 
into  members  of  a  partitioned  data  set  (member  names  are  in  parenthesis 
in  the  Figure).  We  then  chose  members  from  each  of  the  following 
categories  to  form  a  complete  model: 

1.  Application  processing 

2.  Architecture 

3.  Define  Mode! 

■'i .  loading 

The  Application  Processing  group  is  the  nucleus  of  our  IAPS 
met hodol ogy .  It  contains  all  the  IPSS  services  and  facilities  of  the 
SyM  ei'i  Resources  Component  except  for  hardware  facilit  ies  and  the  channel 
program  service.  Also  included  in  this  group  are  the  IPSS  Exogenous 


'•'.vent  Si  ream  component  and  the  Data  Base  Structure  Component. 


Figure  h-1.  Simulator  Overview  of  the  TAPS  Service  Hierarchy 


application  Processing 


F  igure 


- -  , 

Services  (SERVICES) 

Buffer  Mgr  (BUFMR) 

Get  Adderss  (GADRU) 

Get  Input  (RSUF.RDGP) 

Database  (STORAGE) 

Architecture 

IBM  360  Honeywell  Level  6 

Model  30  Model  47 


Hardware  (HDWM30)  (HDWM47) 

Channel  Program  (CHPGM30)  (CHPGM47) 


User  File  Table  (S1DUFT) 

I/O  Processing  Table  (SIDIOPT) 


6-2.  Summary  of  Models  Synthesized  for  Evaluation  of 
Alternate  Hardware  Configurations 
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Table  6-1.  Index  to  Modeled  SIDPERS  Processes 


Level 

SIDPERS  Process 

IPSS 

Endogenous 

Exogenous 

Service  Name 

i 

(IPSS  Initialization) 

INIT 

2 

Arrival  of  SIDPERS  job, 
job  scheduling 

START 

SIDPERS  processing 

APPL 

4 

dob  Step  Execution 

EXGP 

5 

Processing  link  for  OS, 

DBMS,  etc.  (future  use) 

INTF 

6 

SIDPERS  logical  record  to 

DOS  physical  record  mapping 

FMAP 

7 

Buffer  management 

BUFMR 

8 

l 

1 

_ 

Channel  program,  retrieval 
of  records  from  secondary 
storage 

CHPGM 

Ml 

The  Archi torture  group  contains  services  and  hardware  specific 
to  the  two  generic  classes  of  hardware  systems  being  modeled,  namely 
t he  IBM  th0/30  and  the  Honeywell  Level  o.  One  set  (i.e.,  hardware 
specification  and  channel  program)  was  selected  for  each  execution 
o  f  t  he  mode  1 . 

The  Define  Model  group  is  the  IPSS  Model  component.  Each 
member  ,’f  this  group  specifics  a  hardware  alternative.  Using  these 
members,  we  were  easily  able  to  replace  disk  and  operator  console 
units  in  the  model  and  to  ascertain  the  effects  on  the  overall  per¬ 
formance  of  the  system.  The  members  of  this  group  were  easy  to 
generate  and  use.  Clearly  this  type  of  experimentation  is  one  of  the 
primary  benefits  of  modeling  in  IPSS  and  using  the  IAPS  methodology. 

The  last  group  of  members  which  were  selected  were  from  the 
loading  group  which  represents  the  external  (i.e.,  SIDPERS)  loading 
on  the  computer  system.  These  can  be  easily  modified  to  represent 
different  application  processing  characteristics. 

At  the  completion  of  this  research  project  our  program  library 
contains  members  which  represent  (a)  at  least  eight  variations  on  the 
basic  hardware  of  the  IBM  360/30  (CS^)  system;  (b)  two  variations  of 
the  Honeywell  Series  60  Level  6  Model  47  (DAS^)  system;  (c)  a  general 
model  of  computer  software,  including  submodels  of  application  programs, 
a  buffer  manager,  and  a  channel  program;  (d)  tables  of  data  which 
describe  in  detail  the  files  used  by  SIDPERS  (Section  4.3);  (e)  a  table 
wiii eh  describes  the  sequence  of  1/0  and  processing  performed  by  the 
first  four  job  steps  of  SIDPERS,  which  table  is  processed  by  the  first 
submodel  mentioned  previously  in  (e);  (f)  a  eonmv.nd  procedure  in  simple 

question  and  answer  form  which  allows  a  user  to  put  together  and  execute 


a  complete  model  from  the  library  members  described  in  a-e,  and  thus 
easily  to  compare  design  alternatives  (Figure  1-4).  For  a  listing 
of  library  member  names  and  contents,  see  Appendix  K. 

These  models  were  executed  on  an  Amdahl  470  V/6-II  with  OS/MVS. 
Each  model  contained  approximately  2800  lines  of  code  (1PSS,  Fortran, 
and  comments).  Each  model  required  approximately  400KB  of  main 
storage  and  four  minutes  of  CPU  time  (compilation  plus  execution). 
Modeling  experiments  were  facilitated  through  the  creation  of  load 
modules  w'hich  were  repeatedly  executed.  This  reduced  the  simulation 
run  time  by  approximately  one  minute. 
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7.  ANALYSIS  OF  RESULTS  OF  THE  IAPS  SIMULATIONS 

The  ultimate  purpose  of  an  IAPS  simulation  is  to  present  the 
decision-maker  with  data  which  will  prove  useful  in  the  overall 
evaluation  and  comparison  of  alternative  designs.  The  decision- 
maker  will  take  many  things  into  account  which  are  not  addressed 
by  any  simulation,  such  as  the  availability  of  appropriate 
compilers  and  the  projected  cost  of  maintenance.  A  valid 
simulation,  however,  can  provide  information  which  can  be  obtained 
from  no  other  source  except  the  much  more  expensive  alternative  of 
running  the  actual  workload  on  the  actual  computer  system. 

Examples  of  such  information  include  answers  to  the  following 
questions : 

1.  What  is  the  projected  run-time  of  SIDPERS  on  the  DAS^ 
system,  and  how  does  it  compare  to  the  existing  system? 

2.  Which  of  the  hardware  resources  is  over-utilized,  and 

thus  potentially  a  bottleneck  as  system  workload  increases? 

3.  How  will  the  system  respond  to  an  increase  in  workload 
over  time? 

A.  How  will  the  system  respond  if  one  or  more  tape,  or  disk, 
units  become  dysfunctional? 

For  the  simulation  user  to  have  confidence  in  the  results 
produced  by  any  simulation,  he  needs  a  systematic  approach  to  the 
validation  and  analysis  of  the  output  statistics  of  the  simulation. 
It  is  our  purpose  in  this  chapter  to  outline  such  an  approach  in  the 
context  of  our  application  of  the  IAPS  methodology  to  the  hardware 
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comparison  of  the  CS^  and  DAS^  configurations  when  run  against 
the  same  SIDPERS  workload.  However,  we  were  unable  to  carry  out 
this  approach  in  its  entirety  due  to  lack  of  data  and  lack  of 
time. 

In  the  following  sections  we  discuss  model  verification  and 
model  validation,  an  analysis  of  the  results  of  simulating  the 
CS^  and  DAS^  systems  in  six  configurations,  and  the  results 
of  some  additional  simulations. 

7.1  MODEL  VERFICATION  AND  VALIDATION 

Model  verification  is  the  act  of  testing  the  logic  of  the 
model  to  determine  that  it  behaves  as  the  simulator  intended. 

In  short,  it  is  "debugging"  the  computer  program.  During  the 
verification  process,  the  model  may  be  driven  by  real  or  imaginary 
data,  but  is  usually  driven  by  simplified  data  so  that  the  modeler 
can  follow  the  logic  of  the  model  in  detail  by  hand  calculations. 

We  verified  the  IAPS  model  components  by  using  a  detailed  trace 
which  printed  the  occurrence  of  each  event  in  chronological  order 
and  the  value  of  any  variable  whenever  it  changed.  Further 
discussion  of  verification  techniques  can  be  found  in  standard 
simulation  texts  such  as  those  by  Shannon  [SHA75],  or  Fishman 
|  K 1 S  7  3  J  . 

Verification  is  to  be  distinguished  from  val idat ion ,  which 
is  the  act  of  comparing  the  model  to  the  existing  system.  As  a 
part  of  our  IAPS  simulations,  we  compared  the  IPSS  output  statistics 
from  the  model  of  the  standard  IBM  360/30  to  data  collected  at  the 
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Ft.  Stewart  DDC  on  2  August  1979  during  an  actual  run  of  the  SIDPERS 
application  system.  Results  are  presented  in  Table  7-1.  All  times 
are  in  minutes  and  seconds. 

The  first  three  rows  of  Table  7-1  give  the  actual  data  collected 
at  the  Ft.  Stewart  DDC  and  used  for  validation  purposes.  The  lirst 
row  gives  the  elapsed  time  for  each  job  step  (P1A,  P1B,  PIC,  and  PIC) 
and  the  total  elapsed  time  for  all  four  job  steps,  the  source  of 
this  data  being  the  SYSLST.  Since  we  did  not  model  the  operating 
system,  we  adjusted  the  elapsed  times  of  row  one  by  an  estimated  time 
which  represented  the  operating  system’s  I/O  to  the  SYSRF.S  pack. 

The  amount  of  SYSRES  1/0  was  again  known  from  the  SYSLST.  The 
adjusted  elapsed  times,  row  two  of  Table  7-1,  thus  provide  the 
primary  data  for  validation  purposes.  Operator  console  times,  row 
three  of  Table  7-1,  provide  a  secondary  source  of  validation  data. 
These  times  were  computed  by  actually  counting  the  number  and  lengths 
of  messages  on  the  console  log  from  the  2  August  SIDPERS  run,  and 
by  using  our  observation  of  console  speed,  namely  11  characters  per 
second  and  approximately  1/2  second  for  carriage  return.  (IBM  rates 
their  1052  console  at  14  characters  per  second,  but  our  observations 
and  timings  indicated  otherwise.) 

Other  types  of  system  data  useful  for  validation  purposes  include 
CPU  busy  and  idle  times,  other  resource  utilization,  and  queueing 
information.  Due  to  the  lack  of  job-step  accounting  we  were  unable 
to  obtain  any  validation  data  other  than  that  in  Table  7-1.  It  is 
also  recommended  that  validation  data  be  collected  from  more  than 
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Table  7-1.  Validation  Results 


S1DPERS 

Job  Step 

P1A 

P1B 

PIC 

PIC 

Total 

2  Aug  '79 

Elapsed  time  (minutes: 
second) 

4:59 

2:33 

9:23 

3:49 

20:44 

Elapsed  time  less 

RES  1/0 

4:17 

2:13 

8:04 

3:16 

17:50 

Operator  Console* 

1:40 

:  4  5 

:  30 

:  41 

3:36 

(computed) 

IPSS  Model 

Elapsed  time 

4:12 

1:59 

8:0 

3:8 

17:19 

%  difference 

-2% 

-10% 

-0% 

-3% 

-3% 

Operator  Console 

1:35 

:  54 

:  25 

:  41 

3:35 

%  difference 

-5% 

+20% 

-17% 

+0% 

-.5% 

*at  11  characters/second  and  1/2 

second  carriage  return 

bb 


one  run  of  SIDPERS,  and  if  such  data  is  used  for  model  cal ib rati  on 
purposes,  that  a  second  independent  set  of  data  he  collected  for 
validation  purposes.  hue  to  lack  of  time  and  the  difficulty  of 
obtaining  such  data,  we  were  unable  to  obtain  more  than  one  set 
of  data.  Our  identification  of  data  sources  (Table  4-1)  should 
ease  data  collection  in  future  studies. 

Table  7-1  also  gives  IPSS  output  statistics  of  elapsed  time  and 
console  times  for  the  model  of  the  IBM  360/30,  plus  percent  difference 
between  the  validation  data  and  the  model  data.  As  can  be  seen, 
overall  elapsed  time  differed  by  only  3%  and  console  time  by  less 
than  1%.  Based  on  the  limited  data  available  to  us,  we  accepted  our 
model  as  valid. 

7.2  ANALYSIS  OF  SIMULATION  RESULTS 

The  main  statistic  of  interest  in  our  simulation  study  was  job 
(and  job-step)  elapsed  time.  These  results  are  presented  in  Tables 
7-2  and  7-3. 

Table  7-2  presents  the  simulation  elapsed  time  per  job  step  and 
the  total  elapsed  time  for  all  four  job  steps  for  four  variations 
on  the  IBM  360/30  system  and  two  variations  on  the  Honeywell  svstem. 
All  of  the  decreases  in  elapsed  time  except  for  B2  over  Bl  are  to 
be  expected,  judging  by  the  hardware  characteristics  and  comparisons 
presented  in  Tables  5-1  through  5-4.  The  decrease  in  elapsed  time 
of  152  over  151  (about  1  minute,  4  seconds)  is  due  to  a  different 


placement  of  certain  files.  In  its  first  four  job-steps,  SIDPERS 
lias  B  tape  files,  and  models  Al,  A2,  A3,  A4  and  Bl  model  these  tiles 
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Table  7-2.  Simulation  Elapsed  Time  per  Job  Step 
(minutes : seconds ) 


Table  7-3.  System  Comparison 


r 

— 

Alternate  System 

STDPERS  Run-time  on 
Alternate  System  * 
(hours :m i  mites) 

Base  System 

System** 

Alternate  System 
time /Base  System 
time 

i  A1 

Bl 

* 

2:34 

■  (Standard  CS..) 

B2 

.26 

2:0=3 

i 

A2 

.94 

7:31 

j 

A3 

00 

o 

6:24 

! 

1 

A4 

.74 

5 : 5 r. 

! 

A4 

Bl 

.44 

3:31 

(CS.j  witli  fast 

console  and 

B2 

.35 

2:48 

3330  disk) 

^Assumes  a  base 

system  run 

time  of  8  hours 

f  Bl  -  Honeywell  Level  6  Model  47  (DAS^) 

I  B2  -  DAS..  with  2  tape,  3  disk  units 
A2  -  CS^  upgraded  by  3330  disk 
A3  -  CS^  upgraded  by  fast  console 
A4  -  CS^  with  both  3330  and  fast  console 


as  tape  files.  For  model  B2,  however,  the  last  six  of  the  tape  files 
are  placed  on  disk.  (The  remaining  two  tape  files  are  the  SIDPERS 
input  transactions.)  As  can  be  seen  by  examining  Tables  5-1  and 
5-2,  the  average  time  to  transfer  a  block  of  data  is  faster  for 
disk  than  for  tape. 

Two  things  should  be  kept  in  mind  when  examining  Table  7-2. 

First,  we  did  not  model  the  availability  of  storage  space.  No 
claim  is  made  that  any  configuration  (especially  B2)  will  be 
adequate  for  the  storage  of  SIDPERS  files.  Second,  we  assumed 
that  all  tapes  are  premounted  and  that  the  operator  takes  no  more 
than  10  seconds  per  job-step  to  respond  to  console  messages.  These 
two  assumptions  are  consistent  with  our  observations  at  Ft.  Stewart. 
However,  premounting  of  tapes  may  become  more  difficult  on  a  faster 
system  (e.g.,  Bl)  or  impossible  on  a  smaller  system  (e.g.,  B2  with 
only  2  tape  units) . 

Keeping  these  limitations  in  mind,  plus  the  restriction  of  our 
model  to  the  first  four  jobsteps  of  SIDPERS,  we  can  make  a  few 
tentative  conclusions  based  upon  Table  7-2.  We  see  that  the  best 
upgrade  of  the  CS^  system,  namely  A4,  improved  performance  in  terms 
of  elapsed  time  by  approximately  25%.  On  the  other  hand,  either 
of  the  two  DAS^  configurations  improved  performance  by  approximately 
70%  or  more. 

Table  7-3  presents  a  comparison  of  system  A1  to  its  alternates, 
and  a  projection  of  SIDPERS  run  time.  For  example,  the  first  four 
jobsteps  of  SIDPERS  ran  on  system  Bl  in  32%  of  the  time  required  on  A1 . 
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If  the  first  four  job-steps  were  representative  of  all  of  SIDPERS,  then 
we  would  predict  that  an  8  hour  SIDPERS  run  on  Al,  the  IBM  360/30, 
would  take  2  hours  and  34  minutes  on  Bl,  the  Honeywell  Level  6  Model 
47  (with  6  disk  and  6  tape  units).  We  emphasize  that  the  right-hand 
column  of  Table  7-3  should  not  be  taken  as  a  firm  prediction,  but  is 
merely  for  illustrative  purposes.  Such  a  prediction  could  only  be 
made  after  modeling  all  or  at  least  a  substantial  portion  of  SIDPERS. 
Table  7-3  also  contains  comparisons  of  the  "best"  upgraded  version  of 
Al,  namely  A4,  to  the  two  Honeywell  configurations,  Bl  and  B2. 

The  results  in  Tables  7-2  and  7-3  are  illustrative  of  the  type 
of  results  and  comparisons  that  can  be  made  when  evaluating  computer 
systems.  Similar  comparisons  could  be  made  of  other  quantities  of 
interest,  such  as  resource  utilization,  queueing  times  for  resources 
under  contention,  and  response  time  in  an  interactive  environment. 

7.3  ADDITIONAL  EXPERIMENTS  PERFORMED 

To  demonstrate  the  ease  of  model  building  after  a  library 
of  model  components  is  in  place,  we  made  a  number  of  additional 
simulation  runs. 

The  purpose  of  the  first  set  of  runs  was  to  investigate  the 
variability  of  the  estimate  of  elapsed  time  due  to  the  random 
elements  in  the  model.  In  all  experiments,  random  access  was 
modeled  by  picking  the  next  record  to  be  read  (or  written)  in 
a  random  fashion,  by  making  use  of  the  GGU3  random  number  generator, 
a  routine  in  the  IMSL  mathematical  and  statistical  subroutine 
packiige  which  is  documented  in  [LKA73|.  Another  source,  of 


randomness  was  the  random  placement  of  files  on  disk  when  their 
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placement  was  unknown.  The  result  of  these  and  other  uses  of  the 
random  number  generator  is  to  make  the  estimate  of  elapsed  time 
a  random  variable. 

For  experiment  Al,  three  independent  runs  were  made  using 
three  independent  sources  of  random  numbers.  (Run  1  in  each  case 
is  the  run  presented  in  Table  7-2.)  The  results  are  presented  in 
the  first  3  rows  of  Table  7-4.  As  can  be  seen,  elapsed  times  for 
runs  1  and  3  were  identical  (when  rounded  to  the  nearest  second) , 
and  the  elapsed  time  for  run  2  differed  by  only  1  second  in  job-step 
PIC.  This  lack  of  variability  of  the  estimate  of  elapsed  time 
increases  our  confidence  in  its  precision.  Table  7-4  also  presents 
the  results  for  2  independent  runs  each  of  experiments  B1  and  B2. 
Similar  conclusions  can  be  drawn  from  these  results. 

The  purpose  of  the  second  set  of  runs  (A3,  A6,  A7,  and  A8) 
was  to  demonstrate  the  ease  of  building  models  from  an  existing 
library.  All  of  the  eight  additional  runs  in  Table  7-4  were  made 
by  recombining  existing  elements  of  the  library,  and  took  less  than 
one  hour  to  submit  from  an  interactive  terminal  using  the  technique 
illustrated  in  Figure  3-4.  All  four  of  these  models  represented 
upgrades  of  the  CS^  system  (Al) .  In  experiment  A5,  the  2314  disk 
units  were  replaced  by  3340  disks.  In  A6,  the  memory  cycle  time 
was  reduced  by  50%  to  measure  the  effect  of  doubling  CPU  speed. 

In  A7,  six  of  the  eight  tape  files  in  the  first  four  jobsteps  of 
SIDPERS  were  placed  on  disk,  so  that  model  A7  faced  the  same  loading 
as  did  model  B2.  Finally,  model  A8  was  identical  to  model  A4  but 
its  loading  was  that  of  A7  and  B2, 


Table  7-4.  Simulation  Elapsed  Time  per  Job  Step 
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Again  we  emphasize  that  the  systems  modeled  whose  results  are 
exhibited  in  Table  7-4  were  chosen  only  to  illustrate  the  ease  of 
model  building  when  using  the  IAPS  methodology  and  the  types  of 
results  which  a  valid  simulation  can  give  a  decision-maker. 
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8.  SUMMARY  OF  PROJECT  ACTIVITIKS 

Three  people  were  assigned  to  this  project  for  the  methodology  and 
model  building  tasks.  In  addition,  IPSS  maintenance  support  was  provided 
bv  a  hali-time  undergraduate  student.  Work  began  on  approximately 
14  dune  1^79  and  continued  through  14  September  1979.  The  ll’SS  models 
of  the  IBM  and  Honeywell  computer  systems  were  developed,  verified 
and  validated  as  of  21  August  1979. 

Excluding  the  half-time  student,  a  total  of  189  man-days  were 
authorized  for  this  project,  of  which  approximately  IcO  were  used. 

Table  8-1  provides  a  breakdown  by  major  category.  Twelve  days  were 
spent  in  developing  the  methodology  and  24  in  determining  what 
validation  data  was  available  at  which  computer  installations.  This 
is  considered  to  be  a  one-time  cost.  The  User  activities  took  18 
man-days,  exclusive  of  documentation.  The  Modeler  activities  consumed 
18  man-days,  25  of  which  were  in  examining  STDPERS.  Fifty-six  days 
were  spent  developing  the  IPSS  code  for  the  IAPS  methodology,  and  5 
days  were  spent  at  the  IPSS  Analyst  level  of  detail.  Documentation 
consumed  2L  days  and  project  start-up  used  5  days. 

I  able  8-2  compares  the  current  research  project  with  estimated 
’me  1  d. t v  co-fs  |or  several  different  continuing  projects  of  similar 
is.  1.  1  1  ,  o  1  .  t  i *"si  column  give!!  the  actual  man-days  for 

•  i  l  l  .  u  !  1  o  i  ,  c  |  ,  in.1  ;  I  it  en  I  .lb  1  e  8  -  ]  .  Our  t  i  IS.  t  pro  j  OC  t  i  Oil 

,  ■■■>  i  orossi  „i  .’on  Id  c  niiullv  be  a  continuation  of  the 

.  u  r  i  on  t  n  i  o  i .  .  i  .  '  •  is,  ,i  ii..1  i  ,  ■  i  nn  id,  I  i  t  j  nn.i  1  si  mul  at  i  ons 

with  a  I  re.tdv  •  x  :  t  i  n  ■  m,  r  o  i  ,  !  i  '■  r  i  t  _  ,,,  wanted  t  o  cons  i  del 

add  i  t  i on. 1 1  minci  .  c i  i  1 1  i  " i  '  '  .  •  ■  on;  i  \  ’  .  t"  .  w.  •  •  *  o  :  t 
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Table  8-1.  Breakdown  of  Project  Activities 


Methodology 

o  Design  of  IAPS  methodology 
o  Determine  availability  of  validation  data 

User 

o  Determine  architectures  and  variations  to  be 
modeled 

o  Execute  IPSS  models  from  libraries 
o  Validation 

o  Analysis  and  Evaluation 


Modeler 


o  Characterize  IBM  360  Model  30  in  IPSS 

o  Characterize  Honeywell  Level  6  in  IPSS 

o  Develop  SIDPERS  processing  characteristics 
(site  visit,  study  COBOL  programs  and  console 
logs  and  SYSLIST  and  tape  DITTO,  encode  data) 


12 

24 

36 


2 

1 

5 


4 

9 


Simulator 

o  Develop  IPSS  routines  to  input  application  processing 
tables  10 

o  Develop  IPSS  routines  to  process  application 

processing  tables  21 

o  Code  and  verify  the  overall  structure  of  the  iPSS 

model  25 


56 


7(> 


Tab lo  8-1  Continued. 


I  S S  Analyst 

.  o  SLudv  the  inti* rn.it  topic  of  T PSS  on  a  special- 

!  rnsi'  lias  i  s  ') 

s  ! 

!  v  i  sro  I  1  aiiooiis  j 


o  Pro  joot  start-up  Lime  (' 

o  Documentation  21 
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Table  8-2.  Man-Power  Analysis  and  Projection 


Projections  in 

Man-Days 

Activity 

Current 

Research 

Project 

Further 

cs3,  das3 

SIDPERS 

Evaluation 

Evaluation 
With  All  of 
SIDPERS 

Different 

Hardware 

and 

Software 

Operating 

System, 

cs3 

DAS3 

Methodology 

36 

0 

0 

0 

30 

User 

18 

10 

10 

15 

15 

Modeler 

38 

0 

20 

40 

45 

Simulator 

56 

0 

0 

15 

50 

IPSS  Analyst 

5 

0 

o 

0 

5 

Start-Up  and 
Documentation 

27 

10 

10 

10 

_ _ 

25 

180 

20 

40 

80 

170 

tj 


a  man-day  cost  of  10  days  for  running  the  simulations  and  analyzing 


the  results,  plus  10  days  for  start-up  and  documentation. 

The  second  project  we  consider,  of  slightly  greater  scope, 
consists  of  comparing  the  CS^  and  DAS^  systems  with  all  of  SIDPKRS 
as  the  workload.  Modeler  activities  would  consist  of  a  projected 
20  days  to  examine  the  relevant  COBOL  application  programs  and  to 
translate  the  sequence  of  I/O  processing  into  the  IAPS  Application 
Processing  Tahle,  to  collect  the  necessary  data  and  to  encode  it 
into  the  System  Kile  Table  and  Application  i'il**  Tahle;  and  finally 
to  add  these  new  members  to  the  library.  User  activities  would  then 
consists  of  a  projected  10  days  for  making  runs  and  analyzing  the 
results,  plus  10  days  for  documentation. 

The  third  project  involves  the  development  of  the  capability 
to  model  hardware  other  than  the  CS ^  and  DAS.^  systems,  and  to  model 
additional  application  software  such  as  STANKINS.  The  addition  of 
new  hardware  capabilities  would  require  a  projected  20  days  of 
Modeler  activities  and  15  days  of  Simulator  activity.  Specific 
tasks  to  he  performed  would  include  characterization  of  the  new 
hardware,  data  collection,  coding  of  the  data  into  1PSS  statements, 
the  writing  of  a  channel  program,  and  the  addition  of  these  new 
members  to  the  library.  The  modeling  of  additional  software  would 
he  a  project  of  approximately  the  same  scope  as  the  second  project. 

In  summary,  this  third  project,  with  a  total  of  80  projected  man-davs, 
would  be  of  a  scope  similar  to  the  current  project,  but  would  require 
100  fewer  man-davs  of  effort  becuase  of  our  previous  development  of 
the  TAPS  methodoLogv  and  the  pre-existing  library  of  model  components 
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which  represent  application  (I/O)  processing  and  thus  can  be  used 
with  any  hardware  configuration  or  any  new  application  software. 

The  fourth  proposed  project  consists  of  extending  the 
currently  existing  models  to  include  operating  system  components. 

The  current  models  do  not  include  a  representation  of  the  operating 
system.  New  methodology  would  have  to  be  developed,  taking  a 
projected  30  man-days  and  involving  persons  highly  familiar  with 
the  operating  systems  for  the  IBM  360/30  (namely,  DOS-E)  and  with 
that  for  the  Honeywell  system.  Modeler,  Simulator,  and  IPSS  Analyst 
activities  would  require  a  projected  100  man-days.  Specific  tasks 
would  include  extensive  consultation  with  operating  system  experts 
and  data  collection,  plus  the  development  of  IPSS  code  to  represent 
the  operating  system.  User  activities  to  run  the  model,  validate 
it,  and  evaluate  the  output  would  take  a  projected  13  days,  plus 
a  projected  25  days  to  document  the  new  members  of  the  library 
and  the  simulations  performed.  At  least  90  of  the  total  projected 
170  man-days  would  be  one-time  costs,  after  which  the  operating 
system  model  components  would  be  available  in  the  model  library 
for  future  use. 

Provided  that  an  extensive  library  of  model  components  were 
built  up  and  maintained,  future  projects  of  the  scope  discussed  here 
would  tend  to  take  less  time  than  projected.  The  building  and 
maintaining  of  a  large  and  extensive  model  library  of  various 
hardware  and  software  components  is  the  key  to  providing  timely 


answers  to  those  questions  which  can  be  addressed  by  simulation. 


9.  SUMMARY  AND  CONCLUSIONS 


HO 


SUMMARY 

TIi  is  project  was  an  intensive,  short-term  research  anil  ilcve  lopmeiit 
illorl  locum'll  on  tin-  siimilal  ion  ol  n>ni|Mil  rr  systems  lor  l  lie  U.S.  Aim 
Uomputei  Systems  (.oumiand .  Spec  i  I  ically,  we  ailil resseil  tile  problem  ol 
providing  a  model  development  tool  which  wculd  be  responsive  to 
meeting  Command  simulation  objectives.  This  required  a  methodology 
for  model  development,  use,  and  analysis  which  would  be  easy-to-use, 
widely  applicable  to  many  types  of  computer  systems,  amenable  to  change, 
and  time-efficient. 

We  designed,  developed,  implemented,  and  tested  a  methodologv 
to  meet  these  objectives.  Our  methodology ,  called  IADS  ( 1 PSS 
Application  Processing  System),  structures  the  modeling  process 
into  hierarchical  levels  which  identify  spec i I ic  tasks  in  the 
modeling  cycle.  These  levels  are  named  for  the  person  or  persons 
who  are  responsible  for  the  activities  defined  within  a  level.  A 
User  is  responsible  for  the  overall  evaluation  effort.  He  produces 
an  evaluation  of  a  specific  computer  performance  problem  through 
(a)  interactive  model  building  in  an  easy  question  and  answer  format 
(which  results  in  the  submission  of  a  model  for  computer  execution) 
and  (b)  analysis  of  the  results.  The  procedure  for  building  a  model 
uses  Ixi  i  l<l  i  ng-h  I  «>rk  components  from  a  model  library.  The  role  ol  the 
User  presupposes  that  a  Modeler  has  provided  the  appropriate 


Ini  i  I  d  iiig-h  locks  anil  has  made  them  available  for  the  User  in  the  model 
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library.  The  Modeler  characterizes  computer  hardware,  the  software 

for  application  processing  systems,  and  the  data  files.  These 

latter  two  elements  are  characterized  in  a  language  that  we  designed 

and  implemented  as  part  of  this  project.  In  the  role  of  Simulator , 

we  also  wrote  the  program  which  translates  these  characterizations 

into  performance  statistics.  The  Information  Processing  System 

Simulator  (IPSS)  language  served  as  our  base.  IPSS  provides  specially 

designed  built-in  hardware  and  software  language  statements  which 

greatly  facilitated  our  programming  task.  We  completed  the  Simulator's 

task  for  a  large  class  of  application  processing  systems.  Further 

effort,  however,  is  required  for  modeling  advanced  features  such  as 

data  base  management  systems,  operating  system  functions,  and  teleprocessing. 

This  methodology  was  applied  to  an  existing  IKS.  Army  .software 
system  (SIDPERS)  run  on  several  IBM  and  Honeywell  computer  configurations. 

As  Modelers,  we  visited  an  operational  computer  installation  and 
collected  data  on  a  S1DPERS  daily  cycle.  We  also  determined  performance 
specifications  on  the  IBM  Model  30  computer  and  the  Honeywell  Level  6 
minicomputer.  This  software  and  hardware  data  was  encoded  into  IAPS 
source  statements.  Then,  as  Users ,  we  built  models  using  our  interactive 
approacti  and  conducted  a  set  of  experiments  to  analyze  the  performance 
of  several  architectural  variations,  all  executing  witli  the  standard 
SIMPERS  wot  t  lii, ill.  Wo  vei  il  ied  .uni  validated  our  model  ot  SIMPERS  and 
it  ,  rxn  ill  toil  e  il  V  i  I  i  Minton  I  t,.m  IBM  tl>0  Modi' I  10  oomput  el  1  .  Wo  then 
projected  execution  times  for  SUM’ERS  on  a  Honeywell  Level  P  minicomputer. 

Our  results  reflect  the  faster  CPU  and  peripherals  of  the  Level  b  minicomputer. 
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We  varied  the  type  and  speed  of  the  peripherals  on  both  systems  to 
demonstrate  the  responsiveness  capabilities  inherent  in  our  IAPS 
methodology.  Our  primary  measure  in  evaluating  these  alternative 
configurations  was  total  elapsed  time  to  run  the  SIDPERS  job.  We 
also  obtained  queuing  and  resource  utilization  statistics  since  these 
are  automatically  generated  by  IPSS. 

CONCLUSIONS 

The  objective  of  this  project  was  to  produce  a  model  building 
methodology  for  simulating  U.S.  Army  computer  hardware/software 
systems.  The  project  definition  required  a  demonstration  of  our 
methodology  by  building  models  of  an  existing  as  well  as  a  future 
U.S.  Army  computer  system. 

We  designed  our  methodology  based  on  our  perception  of  current 
Army  simulation  needs.  We  implemented  the  methodology  using  the 
Information  Processing  System  Simulator  (TPSS),  and  we  tested  it  using 
a  subset  ol  the  programs  in  the  SIDPERS  basic  cycle.  Two  major 
conclusions  can  be  drawn  from  our  efforts.  One  relates  to  the  use 
of  IPSS  in  modeling  U.S.  Army  computer  systems,  and  the  other  relates 
to  the  IAPS  methodology  for  expressing  application  processing  software 
and  files.  We  conclude  that  IPSS  is  an  appropriate  tool  for  simulating, 
the  type  of  computer  systems  found  within  the  U.S.  Army.  These 
systems  are  Lvpified  bv  a  single  processor,  supporting  either 
uniprogramming  or  multiprogramming,  with  I/O  oriented  COBOL  I ile 
processing  applications.  IPSS  incorporates  special  language  features 
for  charnel  er  i  /.  ing,  computer  hardware  and  files  which  make  it  especially 
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suited  for  the  performance  modeling  and  evaluation  of  these  systems. 

The  IPSS  "service"  concept  helps  the  Simulator  to  produce  a  structured 
solution  to  complex  model  design  problems. 

The  IPSS  methodology  and  language  proved  to  be  relatively  easy 
to  learn  and  use.  Two  of  the  three  researchers  involved  in  this 
project  had  no  prior  ( I'SS  modeling,  experience.  With  a  few  tutorials 
and  IPSS  models  as  a  guide,  they  became  productive  IPSS  modelers  in  a 
short  period  of  time.  The  services  of  an  IPSS  expert,  however,  were 
required  throughout  the  project. 

Although  IPSS  is  a  prototype  system,  no  IPSS  source  code  had  to 
be  changed  to  generate  the  results  produced  in  this  report.  We  did 
identify  enhancements,  however,  and  these  are  detailed  in  the  next 
section. 

Our  second  major  conclusion  is  that  the  IAPS  methodology,  and 
our  implementation  of  its  concepts,  is  an  appropriate  and  useful 
method  for  characterizing  U.S.  Armv  computer  hardware/sof twaro  systems. 
Using  IAPS,  we  were  able  to  represent  many  types  of  file  processing 
quickly  and  easily.  In  addition,  the  representation  of  computer  hardware 
and  the  use  of  this  hardware  during  file  processing  is  one  of  the 
recognized  advantages  of  IPSS. 

We  specifically  designed  IAPS  with  the  objective  of  flexibility, 
generality,  ease  of  use,  and  responsiveness.  We  tested  and  revised 
the  methodology  and  the  implementation  during  the  project  to  more 
completely  satisfy  these  objectives.  We  demonstrated  flexibility  and 
general i I v  bv  modeling,  two  d i f I erent  types  of  computer  svstems  and  several 
hardware  variations.  We  incorporated  case  of  use  by  a  library  building. 


block  approach  to  model  synthesis  and  an  interactive  dialogue. 
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We 

verified  the  responsiveness  of  the  1APS  methodology  by  modeling  some 
of  the  variations  on  short  notice. 

RECOMMENDATIONS 

Our  recommendations  focus  on  three  areas.  first  we  present 
our  recommendations  for  (1)  further  development  of  the  LAPS 
methodology ;  (2)  use  of  the  methodology  by  the  Computer  System 
Command  for  further  modeling  of  computer  systems;  (3)  enhancement 
of  the  IPSS  system  itself. 

IAPS  Recommendations 

Our  experience  as  a  User  of  the  IAPS  methodology  suggests  that 
it  could  be  extended  to  allow  a  more  sophisticated  dialogue  during 
model  synthesis.  We  recommend  the  generation  of  library  members  from 
parameters  input  by  the  user.  Kor  example,  the  User  could  enter  a 
small  number  of  parameters  for  a  sort  operation,  and  the  IAPS  could 
generate  the  appropriate  library  member  for  this  particular  sort  file 
processing.  This  enhancement  would  speed  the  modeling  process  by 
increasing  the  flexibility  and  generality  of  the  library  members. 

In  addition,  the  interactive  model  synthesis  could  have  an  option 
such  as  "tutorial  mode"  to  guide  the  novice  model  builder  in  great 
detail  through  every  step  of  building  a  model  from  the  model  library. 
SiiiIi  .m  addition  to  IAPS  would  greatly  increase  its  ease  ol  use  and 
make  model  building  a  self-taught  procedure. 

The  [APS  methodology  could  also  be  extended  to  include  the 
simulation  of  data  base  management  systems,  operating  system  process  in) 


and  networks  of  computers.  These  would  increase  the  scope  of  the 
methodology  as  well  as  the  accuracy  of  the  results  obtained. 

In  addition,  the  IAPS  methodology  could  be  enhanced  to  allow 
the  Modeler  to  represent  computer  hardware  as  he  now  represents 
computer  files.  This  would  allow  greater  flexibility  in  accommodating 
variations  of  hardware  characterizations  during  experimentation. 

Recommendations  on  the  Use_  of _ 1_APS 

We  recommend  a  continuation  of  the  modeling  effort  which  began 
with  this  project.  In  particular,  we  recommend  modeling  more  of  the 
SIDPERS  basic  cycle  in  order  to  further  test  the  methodology  and  to 
verify  our  projections.  This  study  should  produce  insights  into 
selecting  representative  subsets  of  large  systems  for  modeling  and 
analys is . 

We  recommend  the  establishment  of  model  libraries  incorporating 
common  computer  architectures  and  software  systems.  This  will  enable 
the  Computer  Systems  Command  to  respond  quickly  to  future  simulation 
needs . 

We  also  recommend  an  IATS  simulation  study  he  undertaken  which 
involves  a  hardware  modification.  This  would  involve  simulation  and 
measurement  of  the  system  before  and  after  the  modification.  This 
type  of  study  would  provide  insights  into  the  computer  modeling  process 
as  well  as  a  validation  of  the  IAPS  approach.  The  result  would  he 
increased  confidence  in  the  results  of  this  type  of  simulation  study. 


IPSS  Recommendat ions 

With  minor  exceptions,  iPSS  proved  to  be  a  useful  and  appropriate 
tool  for  our  modeling  purposes.  Many  of  our  recommendations  for  the 
improvement  of  U’SS  are  already  recognized  and  are  in  the  process  of 
being  remedied.  In  particular,  we  make  the  following  recommendations: 

1.  IPSS  contains  few  implemented  features  for  modeling  CPU 
activity.  Since  circumstances  did  not  permit  us  to  model 
tiu-  CPU  in  any  detail,  this  problem  did  not  have  a  major 
impact  upon  our  project,  but  may  indeed  affect  any  future 
modeling  projects. 

2.  Wo  were  forced  to  rely  on  existing  models  and  statement  parsers 
to  determine  which  options  of  the  IPSS  source  code  have  been 
implemented.  We  were  provided  with  a  preliminary  copy  of 

a  document  that  would  remedy  this  situation,  but  its  numerous 
errors  rendered  it  useless.  The  corrected  version  of  this 
document  should  be  published,  however,  in  the  near  future. 

3.  IPSS  provides  only  10  seeds  to  a  random  number  generator 

and  better  random  number  generators  are  known  to  exist.  This 
limits  the  number  of  independent  experiments  one  can  run  to 
10.  We  included  a  better  random  number  generator  and  programmed 
a  routine  to  accept  a  seed  as  input  to  the  model  and  write  out 
the  last  seed  on  model  termination.  These  changes  should  he 
incorporated  as  a  standard  part  of  the  TPSS  package. 

A.  IPSS  does  not  allow  the  modeler  to  save  the  load  module  and  to 
execute  the  load  module  as  a  separate  job  (TPSS  abnormal lv 
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terminates  when  we  tried  this).  As  a  consequence, 
every  time  an  experiment  is  to  be  performed,  the  IPSS 
source  language  compilation  and  Fortran  source  language 
compilation  process  must  occur.  This  consumed  at  least 
one  minute  CPU  time  for  our  models.  We  wrote  special 
routines  to  bypass  this  problem.  These  routines  should 
be  incorporated  as  a  standard  part  of  the  IPSS  package. 

5.  We  could  not  conveniently  model  concurrent  activities 
since  the  IPSS  automatic  save/restore  feature  was  not 
present  in  our  copy  of  IPSS. 

6.  We  could  not  declare  data  sets  with  a  BLOCK  reference 

unit  due  to  an  error  in  the  Fortran  built-in  $CRDS  routine. 
However,  we  were  able  to  work  around  this  error. 

7.  IPSS  does  not  automatically  collect  statistics  on  UNIT 
RECORD  or  UNSPEC  type  devices.  CREATE  DATA  SET  and  GET 
ADDRESS  are  two  very  useful  IPSS  built-in  routines  that 
only  work  on  disk  and  tape  devices.  We  modeled  the 
operator's  console  as  a  Tape  device  to  easily  generate 
the  utilization  statistics  we  wanted. 

8.  A  final  area  of  possible  enhancement  of  IPSS  lies  in 
the  presentation  and  choice  of  statistical  results.  If 
desired  by  the  user,  quantities  such  as  elapsed  time  should 

be  converted  from  the  simulation  time  unit  (e.g.  mil 1 iseconds) 
to  hours,  minutes,  seconds.  It  also  should  be  possible  to 
have  results  talalated  and  printed  botli  cumulatively  and 
over  user  specified  intervals.  We  modeled  SIDPERS  at  the 
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APPENDIX  A 

AN  OVERVIEW  OF  THE  INFORMATION  PROCESSING 
SYSTEM  SIMULATOR  (IPSS) 


This  Appendix  highlights  the  IPSS  methodology  for 
characterizing  salient  features  of  information  processing 
systems,  the  IPSS  simulator,  and  the  IPSS  execution  facility. 
This  Appendix  was  extracted  from  previous  reports  prepared 
by  Dr.  L.  L.  Rose,  Assistant  Professor,  The  Ohio  State 
University  (ROS78,  ROS79) . 


A. 1  THE  IPSS  METHODOLOGY 


IPSS  provides  a  methodology  which,  although  specific  to  computer 
systems,  is  general  in  nature,  and  quite  flexible.  It  affords  the 
user  a  viewpoint  from  which  he  can  construct  a  simulation  model  of 
any  computer  system  at  any  level  of  detail  desired.  This  methodology 
separates  the  characterization  of  a  complex  information  processing 
system  into  separate,  inter-connected  components.  It  gives  structure 
and  direction  to  the  user,  who  has  the  difficult  task  of  defining 
just  what  it  is  he  wishes  to  model. 

Figure  A- 1  illustrates  the  role  of  the  IPSS  methodology  in  the 
design  and  simulation  of  an  information  processing  system.  We 
observe  that  IPSS  provides  the  modeler  a  top-down  approach  to  the 
definition  of  models.  At  the  top  of  this  figure  we  denote  the 
loose  connection  of  user  system  knowledge  into  a  set  of  data  and 
concepts  that  describe  the  Information  System.  This  definition  may 
be  concise  and  complete,  showing  complete  knowledge  of  the  system  and 
processes  to  be  modeled;  it  may  be  very  vague  in  all  respects;  it 
may  be  specific  with  regard  to  certain  aspects  and  non-specific  with 
regard  to  other  aspects  of  the  information  system.  It  is  the  role  of 
the  IPSS  methodology  to  enable  the  modeler,  who  possesses  varying 
degrees  of  information  about  the  information  system,  to  construct 
a  model  at  appropriate  levels  of  detail  to  satisfy  his  modeling 
needs . 

The  TPSS  methodological  view  is  to  characterize  any  information 
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processing  system  as  a  collection  of  four  discrete  but  interfacing 
components.  As  illustrated  in  Figure  A-l  these  components  are: 

1)  services  and  inter-service  procedures,  2)  hardware  resources 
and  configurations,  3)  data  base  resources  and  configuration,  and 
4)  user  workload.  These  four  component  definitions  are  sufficient 
to  characterize  any  information  processing  system;  in  particular, 
computer-based  information  systems  or  manual  systems  can  be 
described. 

Services  and  Inter-Service  Procedures 

The  identification  and  definition  of  services  and  inter-service 
procedures  is  an  important  IPSS  contribution,  and  separates  its 
methodology  (and  subsequent  modeling  activities)  from  other  systems 
such  as  DIMUI  and  CASE.  A  service  procedure  defines  a  task  - 
manual  or  automatic  -  associating  all  related  actions  and  times  to 
complete  the  task.  In  a  computer-based  system,  this  component 
corresponds  to  the  definition  of  all  system  software  facilities, 
to  include  user  application  programs,  the  operating  system,  and 
the  data  management  system.  Service  definitions,  of  course,  are 
constrained  to  the  level  of  detail  required  by  the  modeler  or  to 
the  level  of  knowledge  of  the  modeler.  This  is  true  of  all  four 
component  definitions,  and  forces  the  modeler  to  realize  the  level 
of  detail  appropriate,  and  to  obtain  additional  information,  if 
required,  to  properly  define  each  component.  Note  that  no  computer 
programming  is  being  performed  at  this  time;  we  are  structuring 
the  model  to  be  defined  and  isolating  user  information  into  the 


appropriate  sets  of  component  knowledge .  In  any  computer  programming 
activity,  too  much  emphasis  cannot  be  placed  on  structuring  the 
prototype,  for  correct  and  appropriate  structure  can  be  followed 
by  easy  implementation  which,  by  design,  should  reflect  the  needs 
of  the  modeler. 

Hardware  Resources  and  Configuration 

The  hardware  resources  and  configuration  component  directly 
reflects  the  hardware  system  to  be  modeled.  This  component  defines 
the  CPU,  primary  storage,  tapes,  discs,  drums,  printers,  terminals, 
channel  controllers,  etc.,  and  all  hardware  interconnections.  Again, 
the  level  of  detail  required  is  that  appropriate  to  the  goals  of 
the  modeling  activity. 

Database  Resources  and  Configuration 

The  database  resources  and  configuration  component  defines  the 
logical  database  of  the  system  to  be  modeled,  to  include  schemas, 
file  characteristics,  database  access  capabilities,  and  user  data 
access  and  data  manipulation  facilities.  This  component  can  reflect 
a  current  system  with  normal  non-integrated  file  management  or 
a  future  system  with  fully  integrated  data  management  capabilities. 

User  Workload 

Last,  but  certainly  of  great  importance,  is  the  user  workload 
component.  It  is  here  that  one  characterizes  the  workload  to  be 


placed  on  the  simulated  system,  to  include  workload  description, 
timing  of  inputs,  files  referenced,  etc.  This  completes  the 
structuring  of  the  user's  knowledge  of  the  information  system  and 
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can  be  defined  functionally  or  statistically. 

A  global  view  of  the  resultant  component  is  as  follows: 
work  (input)  to  the  information  processing  systems  emanates  from 
the  user  workload  and  requires  certain  services.  These  services 
may  require  other  services  (inter-service  procedures)  to  perform 
the  work  required.  Whenever  database  accesses  are  required,  the 
database  resources  and  configuration  component  defines  and 
simulates  logical  data  flow  while  the  hardware  resources  and 
conf iguration  component  simulates  the  resultant  physical  data 
flow.  This  is  the  user's  view  of  the  information  flow  process 
at  the  conceptual  level,  structured  into  components  by  the  IPSS 
methodology. 

A.  2  THE  IPSS  MODELING  FACILITY 

Given  the  user's  component  knowledge  as  structured  by  the 
IPSS  methodology,  this  is  transformed  by  the  modeler  into 
model  knowledge  using  the  IPSS  modeling  facility.  This  portion 
of  IPSS  also  provides  structure  and  modularity  to  the  model 
definition,  but  at  a  realizable  level,  as  opposed  to  the  conceptual 
level  of  component  knowledge.  The  result  of  this  transformation 
from  component  to  model  knowledge  is  an  IPSS-defined  simulation 
model  that  can  be  executed  by  the  IPSS  execution  facility. 

There  are  six  model  components  which  comprise  the  resultant 
defined  model.  Given  the  separation  of  user  knowledge  into  the 
Tour  conceptual  components  defined  previously,  it  is  a  straight¬ 
forward  task,  conceptually,  to  define  the  six  IPSS  model  components 


which  describe  system  resource,  storage  structure,  database 
access,  data  structure,  request  stream  and  model  director.  To 
actually  implement  these  modules  represents  a  non-trivial , 
sophisticated  effort  that  requires  not  only  a  good  understanding 
of  the  system  to  be  modeled,  but  also  a  complete  understanding 
of  how  to  effectively  simulate  all  of  the  concepts  and  interactions 
ol  the  process  to  be  modeled. 

IPSS  provides  a  general  simulation  language  and  host  environment 
to  ease  this  task  for  the  modeler.  The  Model  Director  is  supplied 
lor  the  user,  and,  in  effect,  directs  the  simulation  defined  by 
the  other  five  model  components.  It  handles  the  time  clock,  and 
the  events  queues,  and  all  arrivals  and  departures  from  the 
system  during  model  simulation.  CASE  and  D1MUI  effectively 
pre-def  ine  the  entire  simulation  model  (especially  the  system 
resources  model  component).  This  results  in  much  less  understanding 
about  the  model;  it  is  the  IPSS  premise  that  a  modeler  cannot 
effectively  use  a  simulation  model  that  lie  does  not  understand. 

As  a  result,  IPSS  offers  a  set  of  language  constructs  so  that 
the  user  can,  with  relative  ease,  define  all  important  aspects  of 
the  simulated  activity.  Using  the  IPSS  statements,  and  any 
additional  FORTRAN  the  user  may  desire,  a  FORTRAN  model  is 
output  from  the  IPSS  translator  which  can  be  executed  to 
produce  statistics.  Additional  FORTRAN  statements  are  utilized 
by  the  modeler  to  either  add  statistics  unavailable  from  TPSS 
or  to  model  concepts  not  realized  by  the  IPSS  language  constructs. 

In  most  cases,  little  additional  FORTRAN  is  required  as 


IPSS  provides  a  rich  set  of  language  constructs  with  associated 


statistical  capabilities. 

The  top-down,  modular  approach  provided  by  the  IPSS  enables 
the  user  to  define,  using  IPSS/FORTRAN  statements,  five  separate 
model  components  to  characterize  the  system  to  be  modeled.  These 
are  summarized  below: 

1.  System  Resources  -  Contains  definitions  for  all 
information  system  resources  (hardware  and  software)  and  all 
system  tasks  (application  and  operating  system).  This  component 
forms  the  basic  discrete  event  digital  simulator  for  the 
information  systems  model  under  investigation.  Included  in 

the  SYSTEM  (system  resources  component)  is  the  IPSS  supplied 
clockwork  mechanism  to  schedule  and  control  simulated  events 
and  to  determine  when  the  simulation  is  to  terminate.  The 
clockwork  logic  is  based  on  the  next  most  immediate  event 
philosophy  for  controlling  discrete  event  digital  simulations. 

IPSS  statements  which  ease  the  modeler's  task  of  defining 
all  of  the  system  resources  pertinent  to  the  simulation  desired 
include:  Access  Mechanism,  Area,  Buffer  Pool,  Central  Processor, 
Control  Unit,  Data  Channel,  Data  Set,  Device,  Endo  Service, 

Exo  Service,  I/O  Processor,  Main  Storage,  Path,  Procedure,  Queue, 
Reference,  Semaphore,  Task,  and  Volume  statements. 

2.  Storage  Structure  -  Describes  an  information  system's 
physical  data  base  storage  structure  and  its  space  management 
policies.  The  STORE  (storage  structure)  component  interfaces 
with  the  SYSTEM  component  in  three  ways.  First,  it  references 


SYSTEM  to  obtain  Device  and  Volume  facility  definitions.  Second, 
it  supplies  SYSTEM  witli  Data  Set  facility  definitions.  Third, 
it  translates  secondary  storage  references  specified  as  a 
displacement  within  a  data  set's  logical  address  space  into 
physical  addresses  within  the  secondary  storage  address  space. 

Prior  to  a  simulation,  associations  must  be  specified  for  the 
Data  set.  Organization  Method,  Device  and  Volume  facilities. 

A  STORE  Organization  Method  facility  can  be  associated  with  a 
multiple  number  of  SYSTEM  Data  Set  facilities.  The  opposite 
is  true  for  the  Device  and  Volume  facilities.  STORE  Organization 
Method  facilities  are  the  templates  from  which  the  equated  SYSTEM 
Data  Set  facilities  derive  their  definitions  during  a  simulation. 

The  transfer  of  definitions  between  components  is  accomplished  via 
the  execution  of  the  CREATE  DATA  SET  Statement.  The  space 
management  descriptions  in  STORE  are  used  to  calculate 
secondary  storage  addresses  dynamically  during  a  simulation  based  on 
facility  definitions  specified  in  each  component  and  on  the  changes 
of  these  facilities  during  the  course  of  the  simulation. 

IPSS  statements  provided  to  help  the  modeler  define  the  Storage 
Structure  Component  include:  Area,  Segment,  Organization  Method, 
Extent,  Record  Type,  Device,  Procedure,  Reference,  and  Volume. 

3.  Request  Stream  -  Characterizes  the  information  system's 
service  request  stream.  It  is  responsible  for  the  generation  of  all 
exogenous  events  for  a  model.  Whereas  SYSTEM  contains  facilities 


which  characterize  the  processing  requirements  for  each  service  offered 
by  an  information  system,  the  request  stream  component  (REQUEST) 
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de t  ines  the  arrival  of  requrest  for  these  services.  IPSS  converts 
those  times  into  a  composite  arrival  time  stream. 

The  modeler  thus  defines  exogeneous  events,  and  TPSS  eases 
this  task  by  offering  the  Exogenous  Event  statement  and  the  Procedure 
Statement  should  the  modeler  desire  to  define  inter-arrival  times 
functionally. 

4.  Data  Base  Access  -  Contains  the  definitions  of  all  the  resources 
required  by  the  DBMS.  These  include  the  hardware  resources  of  buffers 
and  user  work  areas  as  well  as  application  programs  and  DBMS  software. 

All  DBMS  related  entity-type  facilities  are  defined  within  the  component. 
The  Data  Base  Access  Component  (ACCESS)  is  similar  to  the  SYSTEM 
components  in  that  it  contains  its  own  simulation  clockwork  mechanism 
similar  in  purpose  to  the  one  belonging  to  the  REQUEST  component. 

TPSS  statements  particular  to  the  Data  Base  Access  Component  include: 
DM[,  Service,  Realm,  Schema,  Record  Origin,  Semaphore,  Task,  and  Queue. 

5.  Data  Base  Structure  -  Provides  the  modeler  with  a  set  of 
facilities  which  allows  the  definition  of  logical  data  structures  and 
the  characterization  of  relationships  among  them.  This  can  be  applied 
to  a  variety  of  DBMS  architectures  and  application  environments.  The 
Data  Base  Structure  component  (STRUCTURE)  permits  the  modeler  to 
Investigate  the  effects  on  system  behavior  caused  by  alternate  set, 
record  type,  and  access  path  definitions.  The  definitional  facilities 
provided  allow  the  modeler  to  investigate  a  wide  spectrum  of  logical 
data  structure  organizations  and  allocation  policies. 

Within  the  Data  Base  Structure  Component  are  1PSS  statements  to 


enable  the  modeler  to  define  the  following  important  database  constructs: 
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Realm,  Schema,  Extent,  Record  Type,  and  Set. 

A.)  THE  IPSS  EXECUTION  FACILITY 

The  six  IPSS  model  components  discussed  in  the  previous  section 
(MODEL  being  pre-defined  while  SYSTEM,  S TO RAC E,  REQUEST,  ACCESS,  and 
STRUCTURE  are  user-defined  with  the  aid  of  IPSS  language  constructs) 
comprise  the  input  to  the  IPSS  Execution  Facility.  It  should  be 
under  tood,  however,  that  this  six-component  model  definition  serves 
not  only  as  necessary  input  to  the  IPSS  Execution  Facility.  Of  at 
least  equal  importance  is  the  fact  that  the  user  has  now  created  a 
documented,  readable,  understandable  def init ion  of  the  system  to 
be  modeled.  The  fact  that  this  model  is  explicitly  defined  at 
user-determined  levels  of  detail  for  each  model  component  means  that 
we  have  a  hard  copy  description  of  exactly  what  the  modeler  wishes 
to  simulate.  No  implicit  assumptions  (such  as  are  contained  in  CASE 
and  DIMUI)  exist;  hence  user  verification  of  the  model  can  be 
accomplished  much  more  effectively,  and  the  entire  modeling  effort 
is  at  the  level  of  detail  desired  by  the  modeler. 

The  IPSS  execution  facility  carries  out  the  simulation  as  defined 
by  the  six  IPSS  model  components.  This  execution  requires  translation 
of  IPSS  statements  into  FORTRAN,  link-editing  of  all  required 
object  modules,  saving  certain  user-requested  object/source  modules 
in  the  IPSS  library,  and  executing  the  resultant  load  module.  Were 
the  user  required  to  define  to  the  computer  this  multi-step  job,  a 
great  deal  of  JC1  (mach inc-dependent  job  control  language)  would  be 
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necessary.  In  fact,  both  CASE  and  DIMUI  require  the  user  to  create 
his  own  multi-step  jobs,  a  non-trivial,  machine-dependent  task.  The 
IPSS  philosophy  is  to  remove  the  tedium  and  complexity  of  JCL  from 
the  user;  in  fact,  the  user  specifies  no  JCL  whatsoever  to  execute 
an  IPSS  model.  Thus  IPSS  must  contain,  within  its  own  code,  this 
JCL.  We  find  this  within  the  IPSS  Nucleus,  which  is  written  in 
Assembler  language.  Hence  we  find  that  the  IPSS  is  not  completely 
portable,  but  only  the  Nucleus  must  be  re-written  to  enable 
execution  on  another  dissimilar  machine. 

A.  4  THE  IPSS  STATISTICS 

IPSS  provides  a  modeler  with  a  number  of  statistics  concerning 
the  behavior  of  modeler  defined  entities  and  IPSS  supplied  built-in 
information  system  services.  Many  output  statistics  are  provided 
by  IPSS  automatically;  others  can  be  generated  by  the  modeler's  use 
of  IPSS  commands  to  start/end  data  collection  on  queues,  facilities, 
services,  etc.  The  IPSS-defined  (automatic  or  modeler  invoked) 
output  statistics  fall  into  eight  general  categories: 

1.  Operational  Statistics, 

2.  Request  Stream  Statistics, 

3.  I/O  Activity 

4.  Queueing  Statistics, 

5.  Utilization  Statistics, 

6.  Wait  Statistics, 

7.  Service  Statistics,  and 

8.  Task/Activity  Statistics. 
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Additionally,  the  modeler  can  employ  the  complete  facilites  of  the 
FORTRAN  language  to  develop  his  own  statistics.  Statistics  are 
printed  automat i cal  I v  at  tin*  conclusion  oi  each  model  simulation 
unless  explicitly  inhibited. 
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APPENDIX  B 

TAPS  SOURCE  CODE 


This  Appendix  contains  examples  of  IPSS  source  code. 
Specifically,  it  contains  a  complete  listing  of  the  IPSS 
System  Resources  component  for  the  IBM  360/30  (and  all 
variants  considered  in  this  project).  The  System  Resources 
component  gives  specifications  and  characteristics  of  all 
hardware  components  in  the  model.  Following  this  are  three 
examples  of  IPSS  Services,  which  are  used  to  represent 
software  and  application  program  I/O  and  CPU  processing. 
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STANDARD  INPUT  STREAM  LISTING 


Figure  B-l.  An  Example  of  IAP?  Source  Code 
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APPENDIX  C 

SIDPERS  JOBSTEPS  P1A  THROUGH  PIC 
PROCESSING  CHARACTERISTICS 


This  appendix  contains  the  basic  system  flow  charts 
for  SIDPERS  programs  PlA,  PlB,  PIC,  and  PIG  (Figures  C-l 
through  C-4  respectively) .  For  each  program,  Table  C-l 
presents  a  brief  file  description,  record  length  and  blocking 
factor  specifications,  the  type  of  storage  media  on  which 
the  file  resides,  and  an  indicator  of  file  use  (input  to  the 
program,  output  from  the  program,  or  both  input  and  output). 


A1AAAC 


B1AAAC 


Table  C-l.  File  Characteristic's  for  Programs  P1A  Through  PIC 


Topical 

Input/  Record  Blocking 


File  Name 

Media 

Output 

Description 

Length 

Factor 

P1A 

COO/UC 

Card /Tape 

I 

Optional  Input 

80 

1 

B1AAAC 

Tape 

I 

Input  Stacker  File 

100 

40 

COAAAC 

Tape 

I 

Transaction 

80 

1 

A1AMC 

Tape 

0 

Class-sched  trans 
f  ile 

132 

10 

E1AAAC 

Tape 

0 

SIDPERS  trans 
history 

80 

10 

B1AAAC 

Tape 

0 

Output  Stacker  file 

100 

40 

Cl  CMC 

Disk 

1/0 

Edit  table  file 

506 

2 

XU.JAAC 

(X=A,B,C, 

E.F.R.H) 

Disk 

I 

80 

1 

P1B 

A1AMC 

Tape 

I 

Class-sched  trans 

132 

10 

B1AAAC 

Tape 

I 

Monthly 

100 

40 

C1CMC 

Disk 

I/O 

Edit  table  file 

506 

2 

A1BAAC 

Tape 

0 

Sorted  CS  trans 

132 

10 

B1MAC 

Tape 

0 

SSF 

100 

40 

SORTWK1- 3 

Disk 

I/O 

Sortwork  File 

132 

12 

PIC 

A1BMC 

Tape 

I 

Sorted  CS  trans 

132 

10 

Cl  CMC 

Disk 

i/0 

Edit  table  file 

506 

2 

A1CMC 

Tape 

0 

Edited  trans 

286 

8 
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Table  C-l  Continued. 


1 

i  File  Name 

Media 

Input/ 

Output 

Description 

Logical 

Record 

Length 

Blocking 

Factor 

PIG 

A1CAAC 

Tape 

I 

Edited  trans 

286 

8 

R1GAAC 

Tape 

I/O 

Recycle  trans 

286 

8 

C1CAAC 

Disk 

I/O 

Edit  table 

506 

2 

S0RTWK1- 6 

Disk 

I/O 

*1GAAC 

Disk 

0 

A 

280 

6 

where  *  = 

A,B,C,E, 

B 

285 

8 

F,G,I,J,K, 

m,n,q,r 

C 

285 

8 

E 

285 

8 

F 

80 

20 

G 

125 

25 

I 

84 

20 

J 

90 

25 

K 

280 

6 

M 

80 

20 

N 

80 

20 

Q 

84 

41 

R 

286 

8 

APPENDIX  D 


EXAMPLES  OF  TAPS  INPUT  TABLES 


This  Appendix  contains  a  complete  listing  of  the 
Application  File  Table  (Figure  D-2)  and  System  File  Table 
(Figure  D-d)  for  the  first  four  jobsteps  of  SIDPERS.  It 
also  contains  a  partial  listing  of  the  Application 
Processing  Table  (Figure  D-4),  namely  that  portion  which 
represents  the  first  two  jobsteps  of  SIDPERS  (P1A  and  P1B) . 
For  the  reader's  convenience,  in  Figure  D-l,  we  give  an 
explanation  of  the  headings  for  the  Application  and  System 
File  Tables. 
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Application  File  Table 

FILE  -  a  user  given  unique  identifier  for  each  application  file 
LRECL  -  Logical  record  length  of  application  file 
BLKSZ  -  Blocksize 

//REGS  -  Number  of  logical  records  to  be  processed 
System  File  Table 

FILE  -  Same  as  above,  to  be  used  as  a  cross  reference  between 
the  two  file  tables 

VOLUME  -  Physical  unit  type  (D  for  disk,  T  for  tape,  C  for  console) 
and  unit  number 

LRECL  -  Logical  record  length  from  system's  point  of  view 

BLKSZ  -  Physical  blocksize 

//RECS  -  Number  of  records  on  file 

%PE  -  Percentage  of  records  on  primary  extent 

#SE  -  Number  of  secondary  extents 

K/U  -  Placement  known  (K)  or  unknown  (U) 

TYPE  -  Primary  extent  (P) ,  index  extent  (I),  overflow  (0), 

or  VTOC  (V),  for  disk  files  only 

PLACEMENT  -  Actual  placement  of  disk  file,  if  known,  given  in 

low  cylinder  -  low  track  address  to  high  cylinder  - 
high  track  address 

Figure  D-l.  Explanation  of  Headings  in  Figures  D-2  and  D-3 
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Figure  D-3.  System  File  Table  for  SIDPERS 


i/o  process!  nc  tab  it:  for  application  i 


si  o  p  r  u 


JOPSTLP  *  P  1  A  A AC  A 


input  cnly 

1  CAPD/TA PE  FILE 


-  COOAAC 


I  TAPE  FILE 


7  01  SK  F  iLf  S 

-  AUJAAC.  UJJAAC.  CUJAAC.  FJJAAC,  fJJAAC,  GUJAAC.  MU 


INPUT  t  OUTPo. 
1  TAPE  TILE 


-  01  A  A  AC 


1  O  I  SK  FILE 
-  C 1 C AAC 


OUTPUT  ONE  v 

2  TAPE  FILES 


-  At  A A  AC •  e  I  AA AC 


EAEC  BEGIN  p  l  A  A  AC  A 


INPUT  PROCESSING 


01  X  S  100. 


or  y  s  ioo. 


♦  03  A  S  100. 


COOAAC  -  CARD/TAPE  OPTIONAL  CARO  INPUT 


COAAAC  -  INPUT  TRANSACTIONS 


Figure  D-4.  Application  Processing  Table  for  S1DPKRS  (.Jobstcps 
P1A  and  P1B) 
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APPENDIX  E 

THE  MODEL  LIBRARY 


What  follows  is  a  complete  list  of  the  currently 
existing  members  of  the  model  library,  followed  by  a  brief 
discussion  of  those  members  which  the  User  would  have  to 
be  familiar  with  in  order  to  run  models. 


manamm ili 
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SGADRU  -  1PSS  Get  Address  routine,  modified  for  1APS  methodology 
BIIFMR  -  Buffer  manager 

CHPGM30  -  Channel  program  for  IBM  160/30  hardware 

CHPGM47  -  Channel  program  for  Honeywell  Model  47  hardware 

HDWM30  -  Hardware  specifications  for  IBM  360/30,  all  variants 

HDWM4 7  -  Hardware  specifications  for  Honeywell  Model  47,  all  variants 

M 10 A 2  -  Hardware  configuration  A2  (See  Table  5-3) 

MS0A3  -  Hardware  configuration  A3 

M30A4  -  Hardware  configuration  A4 

M47B2  -  Hardware  configuration  B2 

RDGP  -  Reads  Application  Processing  Table  and  prepare  it  for 
processing 

RSUF  -  Reads  System  and  Application  File  Tables,  and  set  up 

Index  Tables 

SERVICES  -  Application  program  processing 

SIDI0PT  -  SIDPERS  Application  Processing  Table  (for  the  first  four 
.jobsteps  of  SIDPERS) 

SIDSFT  -  System  File  Table  for  SIDPERS 

SIDSFTB2  -  System  File  Table  for  SIDPERS  for  configuration  B2 

S1DSFT2T  -  System  File  Table  for  SIDPERS  with  2  tape  files  (other 

tape  files  transferred  to  disk) 

SIDVFT  -  Application  File  Table  for  SIDPERS 

SID30A1  -  Hardware  configuration  A.1 

SID47B1  -  Hardware  configuration  Bl 


STORAGE 


Generalized  database  description 
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The  following  members  form  the  core  of  the  IAPS  methodology  and 

would  be  in  every  model;  thus  they  need  not  concern  the  User. 

$GADRU 

BUFMR 

RDGP 

RSUF 

SERVICES 

STORAGE 

The  next  group  of  members  define  the  hardware  configuration  and 
thus  require  a  User  choice.  Tne  brackets  indicate  that  a  choice  of 
one  and  only  one  must  be  made. 

STD30A1 

M30A2 

M30A3 

M30A4 

STD47B1 

M47B2 

If  one  of  the  first  four  configurations  is  chosen,  then  hardware 
specifications  will  come  from  HWDM30  and  CHPGM30;  otherwise, 

HDWM47  and  CHPGM47  will  be  used. 

The  second  and  final  decision  made  by  the  User  before  submitting 
a  run  involves  the  workload,  or  loading.  At  present,  there  is  only 
one  Application  Processing  Table,  SIDIOPT,  which  models  the  first 
four  jobsteps  of  SIDPERS,  and  there  is  only  one  Application  File 
Table,  SIDUFT,  which  specifies  the  file  characteristics  of  SIDPERS 
files  from  the  Cobol  programmer's  point  of  view.  However,  there  are 
3  choices  for  System  File  Table,  namely  SIDSFT,  SIDSFTB2,  and 
SIDSFT2T.  The  first  choice,  SIDSFT,  places  all  files  on  disk  and 
tape  units  exactly  as  current  Army  practice,  while  the  latter  two 
offer  slight  variations  on  file  placement  to  accommodate  different 


hardware  configurations. 


r 


In  summary,  to  run  models  the  User  would  have  to  make  two 
choices,  one  on  the  hardware  configuration  desired  and  the  other 
on  the  desired  loading. 


APPENDIX  F 


GUIDE  TO  PREPARING  IAPS  INPUT 


This  appendix  contains  detailed  formatting 
information  for  the  three  input  tables  required  to 
use  the  IAPS  methodology.  The  three  tables  are  the 
Application  File  Table,  the  System  File  Table,  and 
the  Application  Processing  Table.  Examples  of  these 
tables  for  SIDPERS  are  in  Appendix  D. 


L 


Ajij'l  u.it  ion  Kilo  Table  format 

The  «ppl  i  eat  ion  file  table  is  a  description  of  each  file 
application  programmer's  point  of  view. 


Column 


1- 


3 

4-7 

8 


9-14 


13 

16-21 


Code  Kxjil  ;h  i.  i  t_i  o  n 

Any  number  from  A  unique  file 

01  to  30,  no  two  identifier 

identical 

Blank 

Logical  record  length 
(in  bytes) 

Blank 

Blocksize  (in  bytes) 

Blank 

Number  of  logical  records 
in  file 


22-72 


Modeler  comments 


The  system  file  table  is  a  description  of  each  file  from  the 


hardware  point  of  view. 


Column 

Code 

Explanat ion 

1-2 

Any  number  from 

Ol'  to  50 

The  file  identifier  from  the 
application  file  table. 

0 

Any  system  file  not  directly 
referenced  by  a  user's  program 

3 

Blank 

4 

T,  D,  or  C 

T  -  Tape 

D  -  Disk 

C  -  console 

5 

Blank 

6 

Device  unit  number 
(01  to  50) 

7 

Blank 

8-11 

Logical  record  length 

12 

Blank 

13-18 

Blocksize 

19 

Blank 

20-25 

Number  of  logical 
records  in  file 

20 

Blank 

27-29 

Percent  of  records 
in  primary  extent 

30 

Blank 

System  file  Table  Format  (continued) 


Co  Lutmi 

Code 

Kx[>  1  aunt  ion 

31-32 

Number  of  secondary 
extents 

33 

Blank 

54 

K  or  11 

K  -  known  placement 

U  -  unknown  placement 

33 

Blank 

3b 

T,  P,  0,  V  or 

1  -  index  extent 

Blank 

P  -  prime  extent 

0  -  overflow  extent 

V  -  V'i'OC 

Blank  -  prime  extent  (tor  tape 
files) 

37 

Blank 

38-40 

Low  cylinder  address 

The  pair  LCA- LTA  gives  the 
beginning  address  of  the  tile 
on  disk 

(  LCA) 

41 

Blank 

42 

Low  track  address  (LTA) 

4  3 

Blank 

44~4b 

High  cylinder  address 

The  pair  HCA- HTA  gives  the 

(HCA) 

ending  address  of  the  extent 
allocated  to  the  f i 1 e 

47 

Blank 

48-49 

High  track  address  (HTA) 

30-72 

Modeler  comments 

x 


Application  Processing  Table  Format 

The  Application  Processing  Table  describes  the  processing 
performed  by  application  systems.  This  table  allows  the  specification 
of  I/O  activities,  CPU  processing  and  delays.  Table  entries  are 
easilv  grouped  into  identifiable  packets  of  real  world  activities 
(job  steps  and  jobs),  and  allow  for  user  comments. 

a)  Comment  cards  may  appear  anywhere  within  the  application 
processing  input  except  between  an  I,  0,  or  D  processing 
specification  card  and  its  associated  definition  card. 


Column 

Code 

Explanation 

1 

* 

Card  is  ignored  by  processor 

2-72 

User  comments 

Delimiter 

cards  mark 

the  beginning  and  end  of  processing  and 

execution 

groups. 

Column 

Code 

Explanation 

1 

Blank 

2-6 

EXEC 

Begin  an  execution  group 

2-5 

EOP 

End  processing  group 

7-72 


User  comments 


c)  l'roi'i  srfii^;  spiv  i  I  ication 


cards  modi  1  the  input,  output,  nml 
process  i  ng  at  t  i  v i  t  i  us  within  each  process  ing  group. 


Column 

1 


i-  72 


( aid e  I.XJ >  ]  ana  t  ioi I 

B  Lank 

i  1 nput  f  i  1 o 

Zero  or  more  occurences 

Must  proceed  aj  1  "F>"  and  "0" 
cards  within  a  processing  group 

!'  Processing  opt  ion 

One  occurrence 

Must  proceed  all  "0"  cards  within 
a  processing  group 

i  i  Output  file 

Zero  or  more  occurrences 

Must  follow  "1>"  card 

i>  Delay  option 

No  more  than  two  occurrences 

Must  be  the  first  and/or  the  last 
processing  specification  card  in  a 
processing  group 

User  comments 


d)  An  I /0  definition  card  must  follow  each  1  or  0  specification  card. 
Column  Code  Explanation 

1-2  Blank 

3-4  Any  integer  Application  file  number 

from  01  to 
99 


Blank 
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d)  continued. 


Column 

Code 

Explanation 

6 

Blank 

Nonconcurrent  activity 

Any  non-blank 

alphanumeric 

character 

Concurrent  activity 

7 

Blank 

8 

S 

Sequential  access 

R 

Random  access 

I 

ISAM  file 

V 

VSAM  file 

9 

Blank 

10-12 

Any  integer 
from  0  to  100 

Percent  of  records 
processed 

13-72 

User  Comments 

e)  At  least  one  P  definition 

card  must  follow  the  P  specification 

card. 

Column 

Code 

Explanation 

1-2 

Blank 

3 

Blank 

Processing  not  concurrent  with  any  I/O 

Non-blank 

Processing  concurrent  with  associated 

4-9 

Blank 

10-19 

Any  of  the 
codes : 

SORT 

MERGE 

COMPUTE 

EDIT 

UPDATE 

SELECT 

REPORT 

USEREXIT 

Defines  processing  activity 

(Each  code  must  start  in  col  10) 

■)  vconl  inut-il) 


j  99 


la'  1  umn 

Code 

K Kil  l  ana  t  ion 

JO- J'> 

JO-  id 

40-  49 

>0-  >9 

h0-t>9 

Coded  as  eol  10- 19 

1'irst  blank  field  terminates  card 

O  Exact  lv 

one  0  definition 

card  must  follow  each  1)  specification 

card . 

co 1 umn 

Code 

Exp  1  ana t ion 

1-2 

B  lank 

1-9 

Any  nonnegat  ive 
decimal  number 

Estimated  minimum  delay 

(All  3  numbers  should  have  a 
tlocimnl  point) 

10 

Blank 

11-17 

Any  nonnegative 
decimal  number 

Ks t i ma ted  ma  x i mum  d  e 1  a  v 

1  8 

B  lank 

19-29 

Any  number 
between  0.0 

Probability  of  a  positive 
delav 

and  1.0 
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APPENDIX  G 

GRASP  ACCOUNTING  DATA 


The  following  is  a  partial  listing  of  the  measurement 
data  provided  by  the  GRASP  accounting  package.  This  list 
is  included  in  this  report  to  indicate  the  wide  variety  and 
usefulness  of  GRASP  step  accounting  data  to  computer  simulation 
projects. 
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Table  (1-1 


I  Partition 

i 

I 

j  Time-on 

I 

Time- of  1 

Duration 

I 

Non-MPS  duration 

j 

J  Interference  duration 

I 

CPU  time 

Operator  duration 

I/O  wait  time 

i 

i 

|  Phase  loads 

j 

| 

!  Time  waiting  for  LTA 

i 

I 

Time  using  LTA 
Lines  spooled 

Cards  spooled  in 

Cards  spooled  out 

i 

I  Start  I/O  counts 


CKASP  Accounting  Data 


-  identifies  the  partition  in  which  the 
job  executed 

-  time  of  day  the  job  began 

-  time  at  which  the  job  ended  | 

j 

-  time  the  job  occupied  the  partition 

-  time  the  job  would  have  run  without 
interference 

-  time  this  job  was  interfered  with  by  j 
multiprogramming  activity 

-  time  spent  by  this  job  executing  CPU 
instructions 

i 

i 

-  time  spent  by  this  job  in  wait  states  i 
of  3  seconds  or  longer 

i 

-  time  spent  waiting  for  data  transfer  to  i 

complete  1 

f 

-  total  fetches  or  loads  performed  by  thisi 

job  | 

-  total  time  waiting  for  access  to  the 
transient  area 

| 

-  total  time  the  LTA  was  used  by  this  job  j 

-  number  of  print  lines  produced  by  this  i 

job  j 

-  number  of  input  cards  spooled  for  this  ! 

job  j 

-  number  of  cards  punched  and  spooled  lor  I 
this  job 

-  the  number  of  input  or  output  requests 

issued  for  each  symbolic  logical  unit  I 
used  by  this  job  j 


Table  G-l  Continued. 


I/O  device  usage  time 
SYSRES  usage  time 

CPU  utilization 

Channel  activity 
CPU  channel  overlap 

Core  used 


-  the  total  "device  busy"  time  accrued 
on  each  I/O  device  used  by  this  job 

-  time  spent  by  the  job  reading  or 
writing  on  the  SYSRES  device 

-  total  time  the  CPU  was  active  for  any 
partition/purpose  during  the  execution 
of  this  job 

-  total  time  each  channel  was  "active" 

-  overlap  between  CPU  and  channel 
activity 

-  total  size  of  the  program  as  loaded 
into  storage 


4- 


